Protected mode for securing computing devices

ABSTRACT

Methods and systems are disclosed for testing and/or validating that an untrusted device is operating according to an expected state or configuration. The methods and systems may be designed such that the volatile memory of the untrusted device is brought to a known state for validation, for example upon ingress to or egress from a protected mode of operation. The device may execute a first operating system when operating outside of the protected mode. Upon determining to transition to protected mode, an operational image of a second operating system may be loaded into the device. The device may write a pattern to unused memory for validation. The device may receive a first challenge request from a trusted monitor (TM). In order to be successfully validated, the device may answer the challenge correctly within a given response window based on the current state of its volatile memory.

BACKGROUND

Commercial off-the-shelf (COTS) hardware and software may be productsthat are freely available in a commercial marketplace and may generallybe available for public use. COTS products often have the benefit ofbeing low-cost and easily replaced. Additionally, COTS products areoften upgradable in ways that often benefit consumers. As an example,today there are a multitude of COTS mobile devices (e.g., smartphones,tablets, laptops, etc.) available that have a multitude of differentfunctions and capabilities depending on the desired application of theuser. The COTS devices may execute various types of operating systemsand software, for example iOS, Android, and/or Windows. The large numberof features and high degree of customization of COTS devices make themdesirable to various types of users and for a wide range of uses.However, COTS devices may also be an attack target for a plethora ofdiverse threats.

For example, in many instances COTS products may lack certain securityfeatures that allow the product to be fully utilized or trusted. Forexample, COTS communication devices may be unable to achieve basic trustand robustness with software that may or may not be trustworthy. Thus, atraditional COTS communication device may be unable to provide the highlevels of assurance or security necessary to protect various types ofsensitive data.

SUMMARY

Methods and systems are disclosed for operating a COTS device accordingto a protected mode of operation and an unprotected mode of operation.Methods and systems are disclosed for testing and/or validating that anotherwise untrusted device—such as a COTS smartphone—is operatingaccording to an expected state or configuration. The methods and systemsmay be designed such that the volatile memory of the untrusted device isbrought to a known state for validation, for example upon ingress to oregress from a protected mode of operation.

For example, methods and systems for operating a device to be secured ina protected mode of operation are disclosed. Such methods and systemsmay include operating the device outside of the protected mode. Thedevice may execute a first operating system when operating outside ofthe protected mode. It may be determined to transition the device intothe protected mode. In order to save a session associated with operationoutside of the protected mode, upon determining to transition the deviceinto the protected mode the device may hibernate the first operatingsystem. For example, hibernating the first operating system may includestoring operational data for the operating system in non-volatile memoryof the device. Upon determining to transition to protected mode, anoperational image of a second operating system may be operated on thedevice. For example, the operational image of the second operatingsystem may be copied to volatile memory. While in protected mode, thedevice may operate using the operational image of the second operatingsystem. While operating in protected mode, the operational image of thesecond operating system may be static or unchangeable. It may then bedetermined to transition the device out of the protected mode. Prior toexiting protected mode, the device may return one or more portions ofvolatile memory to their original state as configured upon enteringprotected mode. For example, the device may remove any programs orsoftware that were installed during protected mode operation and/orreturn volatile memory to its initial configuration upon enteringprotected mode. Upon transitioning the device out of the protected mode,the device may be configured to restore the first operating system usingthe operational data stored in non-volatile memory.

The device may send a challenge request to a trusted monitor (TM) andmay receive a first challenge from the TM. The first challenge may bereceived based on the device transitioning into the protected mode. Thefirst challenge request may indicate one or more memory regions of thedevice that are to be validated by the TM. The memory region to bevalidated may be associated with at least a portion of the operationalimage of the second operating system and a region of volatile memorythat is unused or idle. The device may determine a first challengeresponse based on the first challenge. The device may send the firstchallenge response to the TM. If the TM successfully validates thedevice based on the first challenge response, the device may then accessto operate on sensitive data (e.g., operate in the protected mode).While in protected mode, the TM may periodically and/or intermittentlyprovide challenges to the device to ensure the device is operating inaccordance with its protected mode configuration. For example, the TMmay challenge the device to ensure that the operational image of thesecond operating has not been altered. The device may send a secondchallenge request to the TM and may receive a second (e.g., or third, orfourth, etc.) challenge from the TM. The second challenge may bereceived based on the device transitioning out of the protected mode.The device may determine a second challenge response based on the secondchallenge. The device may send the second challenge response to the TM.Upon completing the second challenge, the device may exit the protectedmode.

In order to bring unused volatile memory to a known state forvalidation, a pattern may be written to an unused memory region in orderto answer the one or more challenges. For example, a given value to bewritten in the pattern for a given memory address may be inexpressibleas a closed form function of the memory address in order to preventspoofing. The value to be written in the pattern for a given memoryaddress may be dependent on the order in which the memory address wastreated in the pattern. The pattern written to memory may be differentfor each challenge. A pattern may be written to any volatile memorylocations not associated with storage of the operational image of theoperating system utilized in protected mode, not associated with thestorage of one or more utilities or programs utilized during protectedmode (e.g., whose code is known to the TM), and/or not associated withsensitive data utilized during protected mode (e.g., whose values areknown to the TM).

When bringing the volatile memory to a known state for validation, thedevice being validated may receive a plurality of challenge parameters.For example, the plurality of challenge parameters may include one ormore of a random number, an indication of one or more memory regions towhich the challenge is being applied, and/or an indication of a numberof pattern generator cycles over which to apply the pattern to selectedmemory addresses. The device may then write an operational image of anoperating system to a first portion of the volatile memory. The devicemay write a pattern to at least one portion of unused volatile memory.For example, at least one memory address to use for the pattern may beselected in a pseudorandom manner. A value to write to the at least onememory address may be determined based on a value that was stored atanother memory address in the volatile memory and a value of a counterthat was initialized upon beginning the pattern. For example, theanother memory address may be an adjacent memory address to the at leastone memory address.

Upon loading the operational image of the operating system and writingthe pattern to unused memory, the device may perform a integritychecksum across the volatile memory (e.g., once the volatile memory hasbeen brought to the known state). The device may transmit the result ofthe integrity checksum to a trusted monitor (TM) for validation. Forexample, the integrity checksum may be performed first over memoryvalues corresponding to the operational image of an operating system andthen across the at least one portion of unused volatile memory.

The pattern may be written in such a way so as spoofing the challenge isdifficult to achieve within an expected response time window withoutactually writing the pattern to physical memory addresses. For example,a subsequent memory address to which the pattern is written may beselected pseudorandomly based a new (e.g., incremented) value of thecounter. The first memory address in the pattern maybe selected based onthe random number. For example, the first memory address in the patternmay be selected based on a result of a hash function being applied tothe counter and the random number.

The unused volatile memory may be initialized prior to beginning patternwriting. For example, at least one portion of unused volatile memory maybe initialized based on the random number. As an example, initializingthe at least one portion of unused volatile memory based on the randomnumber may include storing the random number at a first determinedmemory address in the unused volatile memory, incrementing the randomnumber, storing the incremented random number at a next determinedmemory location, and repeating the incrementing of the random number andstoring each iteration at a subsequent memory address until the at leastone portion of unused volatile memory has been initialized. Theinitialization may be performed such that, once initialized, the unusedmemory region includes approximately the same number of binary zeros andones (e.g., the number of zeros does not exceed the number of ones bymore than a given threshold and vice versa).

A trusted monitor (TM) is disclosed for validating that volatile memoryof an untrusted device is configured in a known state. For example, theTM may include a communication device configured to send a challenge tothe untrusted device. The challenge may include an indication of amemory region, a random number, and a number of pattern generator cyclesover which to apply a generated pattern to selected memory addresses.The TM may include a processor configured to independently determine theproper challenge response based on an expected state of the volatilememory of the untrusted device and one or more challenge parametersincluded in the challenge request. The expected state of the volatilememory of the untrusted device may include a first region configured tostore an operational image of an operating system and a second regionconfigured to store a pattern. The processor may be further configuredto determine an expected challenge response based on the expected stateof the volatile memory of the untrusted device. For example, theexpected challenge response may include a result of a hash functionbeing applied across data corresponding to the expected state of thevolatile memory. The processor may be further configured to determine anexpected response window (e.g., in the time domain, such as a time atwhich the TM expects a response from the untrusted device) based thechallenge request and a configuration of the untrusted device (e.g.,processor speed, memory size, etc.). The processor may be furtherconfigured to determine that validation of the untrusted device issuccessful based on the TM receiving a challenge response within theresponse window that comprises the expected challenge response. The TMmay be configured to send the challenge request based on one theuntrusted device transitioning into a protected mode of operation. TheTM may be configured to send the challenge request based on or theuntrusted device transitioning out of the protected mode of operation.The TM may periodically and/or intermittently send challenges to theuntrusted device while the device is operating in the protected mode.

An internal reference monitor (IRM) may be an example of a TM that isused to validate that the memory of the device that includes the IRM isstored in an expected state. For example, a device may be configured toexecute an operating system. The device may include memory configured tostore an operational image of the operating system. The memory may alsostore a pattern that is written to at least a portion of the memory thatis not occupied by the operational image of the operating system. Thedevice may include an internal reference monitor (IRM). The IRM may beconfigured to validate that the memory is configured to store theoperational image of the operating system and the pattern. For example,at least one memory address used for the pattern may be selected basedon a result of a pseudorandom function. A value of a counter initializedat the beginning of the pattern may be an input to the pseudorandomfunction. A value written to the at least one memory address may bedetermined based on a value that was stored at another memory address inthe memory and the value of the counter used as the input to thepseudorandom function (e.g., the order in which the memory address iswritten in the pattern may affect the value written to the memoryaddress). As an example, the pseudorandom function may comprise a hashfunction.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description may be best understood when taken inconjunction with the accompanying drawings, of which:

FIG. 1 illustrates an example flow for transition a device into and outof protected mode.

FIG. 2 is a flow chart illustrating an example method for transitioninga device between unprotected mode and protected mode.

FIG. 3 illustrates an example for validating device during transitionsto, operation in, and transitions from protected mode.

FIG. 4 is a flow chart illustrating an example method for transitioninga device between unprotected mode and protected mode where the device isvalidated by a TM.

FIG. 5 is a flow chart illustrating an example method for bringing thevolatile memory of a device to a known state for validation.

FIG. 6 illustrates an example of a memory region to be validated.

FIG. 7 illustrates an example architecture including a COTS device and aTM.

DETAILED DESCRIPTION

As the functionality associated with COTS communication devices (e.g.,cell phones, smartphones, tablets, personal computers (PCs), laptops,workstations, etc.) continues to increase, the proliferation of thesedevices in the market has also dramatically increased. COTS devicesoften offer the benefits of providing state-of-the-art services andfunctionality, while also being easily upgradable and veryuser-friendly.

When used herein, the term COTS device may refer to any computing devicecapable of communicating over a network or performing processing taskson behalf of a user. Although the examples described herein may be interms of providing security or trust for a COTS smartphone or COTSworkstation, the systems and methods disclosed herein may be equallyapplicable to any computing device or communication device for whichadditional security is desired. For example, the systems and methodsdisclosed herein may be applicable for providing additional security forcell phones, pagers, PCs, laptops, vehicles, kiosks, facilities,servers, workstations, tablets, smartphones, routers, modems, local areanetworks (LANs), processors, controllers, microcontrollers, and/or anyother processing and/or communication device.

The terms device and untrusted device may be used herein to refer to adevice for which additional security and/or levels of trust may bedesired. For example, an untrusted device may be a device that, althoughpossessing some security and/or authentication functions/procedures, mayutilize one or more of the systems or methods described herein in orderto achieve additional security or trust. COTS devices (e.g., cellphones, pagers, PCs, laptops, vehicles, kiosks, facilities, servers,workstations, tablets, smartphones, routers, modems, LANs, processors,controllers, microcontrollers, and/or any other processing and/orcommunication device) may be examples of untrusted devices.

For many applications that utilize high levels of security or assurance,there may be a lack of trust in the operation or state of a COTS devicedue to the wide range of cyber exploits that may be used to compromiseone or more of applications running on the device, the operating systemrunning on the device, and/or the physical hardware included in thedevice. In order to utilize COTS devices (e.g., devices that areassociated with various levels of security) to process sensitive data ina secure manner, methods and systems are disclosed to increase the levelof trust associated with a COTS device without altering the hardware ofthe COTS device. The methods and systems disclosed herein may beutilized to protect sensitive information/highly sensitive data (e.g.,data classified as confidential or above) and/or other types ofinformation such as personal data, medical data, data that is forofficial use only (FOUO), other sensitive (e.g., but unclassified) data,and/or any data or processing resources for which additional levels ofsecurity are desired.

For example, it may be useful to allow a COTS device such as asmartphone to be utilized to perform secure voice calls according toNational Security Association (NSA) standards. Other examples of secureprocessing that may be performed in the presence of additional levels ofsecurity may include sending and/or receiving other types of securecommunications (e.g., email, text messages, chats, other sensitive datatransfer, etc.), reviewing/accessing/copying secure or sensitive data(e.g., display of secure documents on a tablet or other COTS device),modifying sensitive data, remote management applications (e.g., remotedesktop applications), and/or the like. Although various techniques forachieving some additional level of security have been advanced (e.g.,including one or more of the NSA Mobility Capability Package forCommercial Solutions for Classified (CSfC), Virtualization of theOperating System (OS) to provide insecure and/or secure containers,hardware roots of trust, etc.), such techniques may provide inadequatelevels of security, may limit the functionality of the COTS device,and/or may lack flexibility for use with a wide variety of COTS devices.

As an example, Mobile Device Management (MDM) applications may beconfigured to validate the characteristics of a device to be secured.For example, the MDM may ensure that a particular radio is disabled,that user passwords are utilized, that the proper user is logged on,etc. An MDM application may enforce a wide range of policy, but the MDMmay be limited to administration and validation functions that utilizeservices of the native OS. The high level checks performed by an MDM maythus be compromised by exploits within and/or hidden to the native OS,preventing the MDM to provide true validation of the security level ofthe device.

For example, a popular open source OS that operates on many COTS devicesis the Android operating system. Historically, Android OS has exhibitedmany flaws and significant susceptibility to potential exploits. Forexample, the North Carolina State University (NCSU) Malware Genomeproject has identified over 1,260 attacks that have been performedagainst the Android OS. Additionally, various applications ranging fromvideo players to document viewers that may run on OSs such as Androidare also known attack surfaces that allow exploitation of the OS.Moreover, the attacks against these areas of susceptibility may changerapidly, making it difficult to prevent future attacks even after aprevious attack has been identified. Flaws in the OS may allowcompromise of the device such that it falsely reports the status of thedevice to the MDM. For example, the malware may have installed aroot-kit that is capable of hiding the compromising malware fromdetailed inspection by knowledgeable users.

Trusted Platform Module (TPM) and/or Mobile TPM (MTPM) have beenproposed by the Trusted Computing Group (TCG) to provide additionallevels of security. TPM and/or MTPM devices may take the form ofcomputer chips that may be embedded in computers and provide hardwareresources for security services. The security protection of TPMs and/orMTPMs may be based on the premise that hardware services can be made tobe much harder to subvert than software-provided services. TPMs and/orMTPMs typically provide services such as signature checking,cryptographic integrity checks, asymmetric public key generation fromprivate/public keys, authentication credential checking, secure storekey(s) for hard disk encryption, etc. The TPMs and/or MTPMs may also bepart of a trusted boot process as described herein. While these featuresrepresent significant security services, TPMs and/or MTPMs may notassure that software running on the device is free of malware, which mayprovide a significant risk if sensitive data is processed on the device.

Trusted Boot is an example of an approach that may be used to reviewsource code prior to instantiation of an OS. Trusted boot may preventthe loading of drivers and/or OS loaders that are not signed with anacceptable digital signature. For example, the source code may bereviewed by a trusted process and used to generate an executable binaryimage for the OS that cannot be changed except under certain controlledcircumstances. The binary image may be validated prior to allowing theprocessor to operate using the image. In an example, the trusted bootverification process may utilize a trusted hardware component thatprevents changes to the boot loader.

Moreover, prior to loading the binary image of the OS from a file thatis stored in non-volatile memory, an authorization request and/or anintegrity check may be performed on the OS files to ensure they have notbeen modified. For example, the boot loader may validate the OS beingloaded using a signature check that validates the source of the image.An integrity check of the stored file may be utilized to ensure that thestored file has not been modified. If the authentication test and/orintegrity check are passed, the trusted boot loader may instantiate andstart the trusted image on the computer. The type of assurance utilizedfor operational security may vary depending on the application, but mayinclude review of the source code implementing security relatedfeature(s) and/or review of the complete OS.

However, trusted boot using a general purpose COTS OS may fail to resultin the expected image being present in volatile memory, for examplesince the OS may include flaws that could allow the OS to be compromisedafter it is put into operation. For example, even if the file to beloaded passes signature and integrity checks, the operational image maylater be infected with malware. Also, while the OS file(s) that arestored in non-volatile memory may be validated during a trusted boot,the operational image (e.g., the image that is present during operationof the operating system) may not be easily comparable to the boot filebecause one or more data structures and/or processes of the boot filemay be stored in a different form than would be present during OSoperation. For example, in the many boot processes, the OS file storedin non-volatile memory is not typically copied directly to dynamicmemory by the boot loader. Instead, some programs are copied to dynamicmemory and some (e.g., typically many) commands and/or scripts may beexecuted to create the dynamic memory image of the OS.

Therefore, since many types of COTS operating systems (e.g., Android OS,Linux OS, Apple iOS, Microsoft Windows OS, etc.) may be subject tonumerous types of attacks that are difficult to prevent in advance,relying on a trusted boot process alone may still lead to data and/orresources being compromised. Trusted boot processes may also still allowfor undetected compromise after the boot process is completed.

Rather than or in addition to trusted boot approaches, a dual bootapproach may be utilized in order to increase the security of acomputing platform. When utilizing dual boot, the user may select acertain disk partition and/or OS to initialize the computer. Thus, theuser may be able to select the appropriate primitive boot loader (e.g.,which may possibly be a part of the system Basic Input/Output System(BIOS)) that will instantiate on the dynamic/volatile memory of thecomputer and will become the OS of the computer.

During dual boot, a boot menu may be used that offers the user aselection of initialization options. Often, these multiple boot imagesor disk partitions have nothing to do with each other and are presentbecause the user wishes to use different OSs for different purposes. Forexample, one OS may be used for performing word processing of documentswhile another OS may be used as a web server and/or for web pagedevelopment. In an example, a trusted boot technique may be utilized asone option of the multiple boot-time options a user may select. However,even if trusted boot is used as an option during a dual boot approach,there may be an assumption that the user knows if a secure session isneeded at the time of boot. By relying on a boot time decision todetermine whether a trusted boot should be performed, it can be verydifficult to integrate secure and non-secure functionality in order toincrease overall usability. For example, at the time of boot, a user maynot know whether or not a COTS phone will receive a request to perform asecure phone call that may implicate the use of increased securityfeatures. If either the increased security of a trusted boot or theinstantiation of a native COTS OS is to be selected at the time ofinitial system boot, it may be difficult to integrate functionality thatutilizes high levels of security with other personal computingactivities such as playing games, performing navigation, browsing theInternet, etc. These personal applications may be associated withsecurity requirements that differ, while boot-time selection may rely onthe user to carefully and manually configure the device. Moreover,trusted boot approaches may not increase of operational security afterboot, as the trusted boot monitor may be configured to simply monitorwhich boot partition was selected without providing operational securityfeatures during OS operation. Such a system may fail to detect threatsthat corrupt the device subsequent to the initial boot process.

In order to prevent malware installed on the native COTS OS fromcompromising functions that are require high levels of assurance orsecurity, a computing device such as a COTS devices may be configured toimplement a protected mode of operation. The protected mode of operationmay be associated with an increased security and/or a limited set offunctions for which monitoring and validation may be more easilyachieved. For example, based on one or more triggers such as a requestto utilize secure processing and/or perform a secure function, the COTSdevice may be configured to automatically and/or transparently replacethe Operating System (OS) executing on the COTS device with different OSthat may be referred to as a Secure OS. The Secure OS may be associatedwith a more limited functionality than the original OS.

For example, the Secure OS may operate utilizing a limited number ofapplications (e.g., may allow certain applications to execute but notothers), may restrict memory access (e.g., restrict access to volatilememory), and/or may prevent access to certain types of hardware (e.g.,such as radios or other communication devices). The Secure OS maymonitor one or more applications and/or memory locations to ensure thatthe Secure OS and/or applications operating on the Secure OS areexecuting according to expected or desired behavior. The Secure OS maybe configured to implement one or more methods for detecting malware orother malicious code within the Secure OS and/or other memory regions ofthe COTS device. While the Secure OS is in operation, the COTS devicemay be said to operate in Protected Mode.

In an example, the Secure OS may be a functionally reduced version ofthe native OS. For example, the native OS may be Android (e.g., or someother OS present on a smartphone), and the Secure OS may be a paireddown or functionally reduced version of Android that eliminates orreduces one or more avenues for malicious attack. For example, thereduced version of the native OS utilized during protected modeoperation may restrict access to physical resources such as theprocessor, periphery devices, memory locations, communication modules(e.g., radios, modems, etc.), and/or the like. The functionally reducedversion of the native OS that is used as the Secure OS may includelimitations on services offered during operation.

The secure OS may be a different OS than the native OS and maycompletely replace the native OS during operation in protected mode. Inan example, the Secure OS may be owned, secured, and/or maintained by anadministrator (e.g., specified company, government, entity, etc.). TheGreen Hills Integrity OS may be an example of a Secure OS.

Utilizing the Secure OS while in protected mode may increase theassurance and/or security of the COTS device in one or more ways. Forexample, by utilizing the Secure OS, the potential avenues for attackand/or introduction of malware may be limited. As an example, if theSecure OS provides fewer services than the native OS, it may be moredifficult for malware to infect the Secure OS since there are fewerservices for the malware to exploit. Programs such as media players, webbrowsers, networking services, etc. may be restricted or limited whenthe Secure OS is in operation in order to reduce the number of potentialattack surfaces. By reducing the number of programs and/or executablethat operate during the protected mode, the device by able to betterensure that the secure OS is not polluted based on the history andresidual changes caused by insecure user activities.

For example, the native OS may be Android and the Secure OS may be aversion of the Linux OS. The Linux OS may be simpler and may providefewer system services than Android, thus limiting the avenues of attack.Examples of Android services that may be the object of a potentialattack may include the Service Manager, the Dalvik virtual machine (VM),and/or the Binder, which may be utilized to provide inter-processcommunications. One or more (and/or other) of these Android modules maybe stopped, restricted, and/or configured to operate in a privilegedmode if a reduced version of Android is utilized for Secure OS operationin protected mode. In an example, the Secure OS may be a version of theLinux OS that does not utilize Android the Service Manager, the DalvikVM, the Binder service, and/or one or more other Android services ormodules that may be prone to attack.

The COTS device may be said to operate in an Unprotected Mode (e.g.,with a relatively lower level of security than when operating inProtected Mode) when the native COTS OS (and/or some OS that isdifferent than the Secure OS) is operational. During periods in whichthe device is operating in Unprotected Mode, the device may be operatedwithout use of the Secure OS. Instead, the native COTS OS may be inoperation and native and/or installed applications may be free tooperate according to the policies of the native COTS OS. The securityrelated functionality of a COTS device operating in Unprotected Mode mayvary, for example depending on the type of COTS device, the use of theCOTS device, the capabilities of the COTS device, the operation of thenative COTS OS, the types of applications operating in the native COTSOS, etc. As may be appreciated, although operation utilizing the nativeCOTS OS may be referred to as Unprotected Mode, the COTS device maystill implement various forms of security and integrity duringoperation; however, the type and/or degree of security provided by thenative COTS OS and/or applications running on the native COTS OS may bedifferent than that provided by the Secure OS when operating inProtected Mode.

For example, when operating in the Unprotected Mode a user may desire toutilize functionality associated with a relatively higher level ofsecurity. For example, the user may select an application that isassociated with an increased level security (e.g., a Secure voice call,establishing a secure communication session, transfer or processing ofdata deemed to be sensitive and/or secure). Upon receiving the requestto utilize a secure application, the COTS device may automaticallyand/or transparently transition from the Unprotected Mode to theProtected Mode. The Protected Mode may operate the COTS device using aSecure OS.

Additionally, methods and systems described herein may be utilized todetect changes caused by malware. Systems and methods are described toprevent exposure of protected data while the device is operating in anUnprotected Mode. Systems and methods are described to protect unused oridle memory in the COTS device in order to prevent the unused or idlememory from being exploited by malware, for example during thetransitions between Protected Mode and Unprotected Mode.

Transitioning to the protected mode may include changing from afull-featured OS (e.g., a native COTS OS) to a Secure OS. The Secure OSmay implement additional security features as compared to the OSutilized during unprotected mode operation. FIG. 1 illustrates anexample of transitioning from unprotected mode to protected mode andback to the unprotected mode. As an example, FIG. 1 may be describedwith respect to a COTS smartphone that executes the Android OS.

For example, at 102 the device may be configured to utilized the COTS OSwhile the device is in unprotected mode. The COTS OS may be the nativeOS of the device or some other installed OS. For example, the COTS OS ornative OS may be a commercial version of Android that is executing on aSmartphone. During unprotected mode operation, the device may be runningapplications that were native to the COTS device and/or applicationsfrom third parties that were installed on the device. During unprotectedmode operation, the device may utilize various drivers and/or peripheralhardware (e.g., communication modules such as radios and/or modems, userinterfaces such as touchscreen displays and/or keyboards, other attachedequipment, etc.). Applications may access hardware and other processingresources via the native OS. While operating in unprotected mode, theamount of security available to the user may be determined based on therelative level of trust in the native OS and/or the boot loader thatinstantiated the native OS and/or configuration of the device.

At 104, the device may determine to transition from unprotected mode toprotected mode. For example, the user of the device may determine that asecure call is to be invoked. In an example, the user may select aSecure Call application and/or some other application that is associatedwith a heightened level of security. The Secure Call application orother application that is associated with a heightened level of securitymay be selected while the device is operating in unprotected mode andrunning the native COTS OS. Selection of various (e.g., one or more)applications running on the native OS may be a trigger to transitionfrom unprotected mode to protected mode. The transition may occur whilethe native OS is in operation and may be performed without completelyrebooting or shutting down the native OS. However, in some examples thetransition may also be performed where the entire native OS is shutdown.

Rather than, or in addition to, transitioning from unprotected mode toprotected mode based on the selection of an application associated witha secure task, the transition from unprotected mode to protected modemay be based on implicit criteria. In other words, the device may beconfigured to determine to transition from unprotected mode to protectedmode without receiving an explicit command or request from the user toperform such a transition or to invoke an application associated withprotected mode operation. For example, the COTS device, while operatingin unprotected mode, may receive a request to establish a secure callwith another peer. The device may determine to transition to protectedmode from unprotected mode based on the request. Other actions performedby the user of the device may cause the device to enter protected mode.For example, the user may request access to data that is deemed to besecure, may invoke an application that is associated with secureprocessing, and/or the like.

When transitioning from unprotected mode to protected mode, the nativeOS may be suspended by the device. For example, an application runningon the native OS (e.g., the application that invoked the transition fromunprotected mode to protected mode such as a “Go Secure” applicationand/or a secure call application) may hibernate the native (e.g.,insecure) OS. For example, the application may copy the native OSoperating image that was stored in Random Access Memory (RAM) tonon-volatile memory such as flash memory and/or a hard disk. In anotherexample, the native OS may be terminated and the operating image may bedisregarded. However, by storing a copy of the image of the native OS ina file stored in non-volatile memory, the image can be used to reloadthe native OS when secure processing is complete and the devicetransitions back to unprotected mode from protected mode. Returning thenative OS to its previous state from prior to the unprotected mode toprotected mode transition may allow for a more robust and meaningfuluser experience, as the user would be permitted to return to previousinsecure tasks after secure processing is complete.

At 106, once the image of the Secure OS has been loaded on the device,the device may operate in protected mode using the Secure OS. Forexample, the user may perform a secure call. While in protected mode,the device may perform one or more secure functions such as performingsecure calls, sending electronic mail, utilizing remote desktopapplications, and/or executing other applications for which heightenedlevels of security or assurance are desired.

At the end of the secure operation (e.g., a secure call is terminated),at 108 the device may be configured to transition from protected mode tounprotected mode. For example, prior to the Secure OS being terminated,the Secure OS may “wipe” the memory of the device to ensure thatsensitive data is not exposed outside protected mode. Memory regionsassociated with protected memory operation may be cleared, zeroed,written to a predetermined pattern, written to a random or pseudo-randompattern, replaced with the data that was stored there prior to enteringprotected mode, and/or the like. In an example, the device may bereturned to an initial state associated with the transition fromunprotected mode to protected mode prior to exiting the protected mode.Returning to an initial protected mode state (or some other known state)may help ensure that secure or sensitive data that is operated on whilein secure mode does not persist across the transition back tounprotected mode operation. The Secure OS may automatically restore theinsecure image of the native OS (e.g., which may have been stored duringthe transition from unprotected mode to protected mode). Restoring thenative OS such that the device returns to unprotected mode may betransparent to the user of the device. Once the sensitive data has beendeleted, the memory region including the operating image may be clearedand/or replaced with the operating image of the native OS. In anexample, the transitioning process may cleanse or erase some or allmemory utilized by the Secure OS while in protected mode. At 110, thedevice may operate in unprotected mode using the restored image of thenative OS, for example in a manner similar to that described at 102.

When operating in protected mode using the Secure OS, Secure OS controldata may be configured to provide additional protection from malware.For example, many types of malware such as rootkits may hijack orotherwise manipulate control flows of the OS in order perpetrate anattack. For example, the malware may attempt to modify control dataand/or hooks in the kernel space in order to compromise the OS. In orderto combat such an attack, the Secure OS may be configured to consolidatecontrol data associated with the Secure OS into protected memoryspace(s). For example, the Secure OS may prevent other processes otherthan the Secure OS from modifying the control data included in theprotected memory space. The memory that stores the sensitive controldata may be protected using techniques such executable space protection(e.g., a VMM, if used, marking of memory regions as non-executable, suchthat an attempt to execute machine code in these regions will cause anexception), and/or the like in order to prevent subversion whileoperating in protected mode.

The use of the Secure OS may form a layer of isolation between theunprotected mode and the protected modes. The isolation may be ensuredby appropriately clearing and/or limiting memory access during modetransitions. Isolation of secure and insecure processing may be achievedby overwriting some or all memory not being used by the Secure OS,resident utilities utilized during protected mode, and/or applicationsutilized during protected with a specific data pattern. By overwritingunused memory with a specific pattern, additional protection may beachieved to prevent or mitigate the risk of attack by programs ormalware that may utilize the unused memory locations.

In order to provide a controlled environment while operating inprotected mode, one or more interfaces and/or subsystems of theuntrusted COTS device may be restricted and/or disabled during operationin protected mode. For example one or more radio(s), processor core(s)(e.g., processing cores other than the primary core), electricalinterfaces (e.g., USB, etc.), and/or the like may be disabled duringprotected mode operation.

Thus, by operating applications and/or processes that do not requirehigh levels of security in a less-secure, unprotected mode (e.g.,utilizing a native COTS OS) while automatically transitioning to aprotected mode that utilizes a more secure OS to support higher levelsof application and/or processing security, the capabilities andusability of COTS devices can be leveraged for everyday applicationswhile still providing high levels of assurance when protected mode isentered. The transitioning between modes may be transparent to the userin order to provide a fluid user experience.

Transitions between protected mode and unprotected mode may be securedusing various techniques. For example, the device may be configured toperform certain actions each time the device enters protected modeand/or each time the device exits protected mode. The actions may bedesigned to ensure each time a transition between protected mode andunprotected mode occurs that the entire device is brought to a knownstate. So state transitions may provide a level of isolation between theprotected mode and the unprotected mode by ensuring that each modebegins operation from an expected state and data from a previous stateis not maintained across a state transition.

For example, when a device transitions from unprotected mode toprotected mode, the volatile memory (e.g., RAM) used to instantiate theOS may be restored to the known, predetermined binary image of theSecure OS to memory. By ensuring the volatile memory is restored to theexpected binary image of the Secure OS, it may be asserted that theSecure OS does not include malicious malware and that the Secure OS willoperate according to its expected functionality. In order to preventmalware from affecting protected mode operation, the Secure OS may beconfigured to generate and write a data pattern in some or all memorylocations that are not occupied by the Secure OS and/or associatedresident utilities or applications of the Secure OS. Writing the patternto the unused volatile memory may be the first operation or taskperformed by the Secure OS, and such a pattern may be written prior toany other application being run in protected mode. In this manner, inaddition to ensuring the binary image of the Secure OS is established toa known state upon transition to the protected mode, the remainder ofthe volatile memory that could be used as an attack path can be ensuredto be set to an expected value. Such a transition may reduce oreliminate degradation of the secure state of protected mode operation bypotential malware that may be present in the unprotected mode OS. Byensuring the Secure OS is loaded from a trusted binary image and writinga pattern to unused memory locations when entering the protected mode,the device can ensure that malware installed while operating in theunprotected mode is unable persist across the transition to protectedmode.

After entering protected mode, the volatile memory of the device that isnot used by the Secure OS may be used by applications to be run inprotected mode. For example, one or more memory regions over which thepattern was written to memory may be used to execute one or moreapplications. The secure application(s) may be executed during operationin protected mode, and one or more trusted, non-resident applicationsoperating in the memory unused by the OS may be used. Applications to beinstantiated while the device is in protected mode may be validated(e.g., by the Secure OS) by authenticating a signature and/or validatingintegrity information (e.g., an integrity check) included with theapplication. One or more applications or utilities may be preinstalledand checked/validated with the Secure OS when entering and/or exitingprotected mode. One or more other applications may be installed afterentering protected mode, and such later installed applications mayutilize authentication and/or integrity checks prior to execution.

In order to prevent modification of the Secure OS that may provide apotential avenue of attack, the Secure OS memory image may be maintainedas constant or unchanged. Thus, each time the image is restored (e.g.,when protected mode is entered), the Secure OS image may be the same asfrom previous times it was invoked. In order to ensure that the SecureOS image has not been modified, prior to restoring the image to RAM sothat it can begin executing, the Secure OS image may be validated, forexample by comparing an integrity checksum of current state (e.g., anintegrity checksum performed across the volatile memory image) to aknown or expected value of the integrity checksum. The integritychecksum may be a datum or data that is determined based on the contentsof the data being validated. The integrity checksum may result indifferent output values for different bitstreams. Therefore, if theexpected state of the device does not match the actual state uponvalidation, the result of the integrity checksum may be different thanthe expected result, meaning that the validation may fail. Examples ofintegrity checksums may include one or more of digests, hash functions,fingerprint functions, a cyclic redundancy check (CRC), a cryptographichash function, and/or the like. If the validation is successful,operation in protected mode may be permitted to continue.

In an example, the Secure OS may be specifically configured to bevalidated to ensure that it has not been modified from its originaldistribution. Changes from the distribution version of the Secure OS maybe indicators of infection of compromising malware and/or root kits. Toprevent such an security compromise, the Secure OS may be configured insuch a way that it is not modifiable by user operations while in eitherprotected or unprotected mode, and the image that is loaded each timethe device is transitioned into protected mode may be the same for eachinstantiation. This may be different than the typical techniquesutilized to instantiate an OS, which may utilize one or more scripts orprocesses during OS loading that may modify the contents of theoperational image of the OS. If such scripts are executed during OSinstantiation, the memory image created may be slightly different eachtime the OS is loaded, making validation more difficult or more complex.By utilizing the same stored image of the Secure OS each time protectedmode is entered—unlike the common, conventional OS loading—theoperational image for the Secure OS may be the same each time it isinstantiated. Portions of memory may be intermittently and/orperiodically tested by the Secure OS to validate that applications areexecuting in their expected state and/or to ensure memory regions havenot been compromised with unexpected data structures.

In example, the image of the Secure OS may be loaded on one or moredevices operating in protected mode. For example, the same Secure OSimage may be used on a plurality of devices of the same class. TheSecure OS may be configured based on the class and/or capabilities ofthe device operating in protected mode. For example, the Secure OS maybe customizable based on the original equipment manufacturer (OEM)vendor of the device, the hardware configuration of the device, thepurpose or use of the device, and/or the like.

FIG. 2 is a flow chart illustrating an example method for transitioningfrom unprotected mode to protected mode and back to unprotected mode.For example, at 202 upon determining to transition from unprotected modeto protected mode the device may hibernate (e.g., or otherwise suspendor terminate) the COTS OS (e.g., the OS that executes while the deviceis in unprotected mode). The termination of the COTS OS may be performedsuch that the unprotected mode session is not saved (e.g., the native OSis completely shutdown and/or the operating image of the native OS isdeleted or disregarded). In an example, hibernation may be used in orderto save information related to native OS operation for re-instantiationupon egress from protected mode. In the case many popular operatingsystems, hibernation may be utilized to preserve data of the unprotectedsession and may be invoked via the COTS OS. The operational volatilememory data and other data associated with the unprotected mode sessionand/or COTS OS may be written to a non-volatile storage device. Althoughhibernation may not be directly supported by the Android OS, hibernationmay be achieved using the underlying Linux OS that forms the kernel forAndroid. Since applications intended for the Android OS are written suchthat they may be killed or terminated at any time, in some examples theunprotected mode session/OS may be terminated without storing stateinformation or other data. In an example, the unprotected sessionincluding the COTS OS may be terminated and restarted upon egress fromprotected mode. Application(s) running in the COTS OS that areconfigured to transition the device to protected mode (e.g., a “GoSecure” app, a “Secure Voice Call” app, other apps that trigger securityrelated functions or applications, etc.) may be configured to operatewith system privileges that allow the application(s) to invoke or startthe Secure OS.

At 204, the Secure OS may be started. In order to ensure that the SecureOS is loaded in a known or predictable state, the Secure OS image may berestored (e.g., the reverse operation to hibernation) using an imagethat was previously validated and/or authenticated. In an example, theSecure OS image may be started in the volatile memory from storage(e.g., a Boot or Kexec operation). For example, a Kexec operation mayperform a system call that shuts down the kernel for the COTS OS andstarts the kernel associated with the Secure OS. The Kexec operation maybe similar to a reboot operation but may be independent of the COTSdevice firmware. Uboot may be an example of a boot loader that isembedded in Linux systems that be used to load the Secure OS. The imageof the Secure OS may be created from a snapshot taken of the Secure OSas loaded for its intended configuration and/or may be created through adeterministic source code compiler. Examples of OSs that may be used asa basis for the Secure OS may include Windows (e.g., Windows inSafe-mode), Linux, and/or Green Hills Integrity. The specific OS chosenmay be selected based on implementation specific security requirements.

The hardware and kernel for the Secure OS may be configured to minimizeattack surfaces. For example, the Secure OS image may be configured suchthat Secure OS control data and/or Secure OS hooks may be aggregated orconsolidated into a protected memory space. In an example, the Secure OSmay be configured to control virtual memory by placing security-relatedand/or security-critical functions in protected Secure OS memory and/orsome other secure physical memory location. The protected Secure OSmemory may be a form of physical memory and may use physical memoryaddressing modes. A physical memory addressing mode may refer to asystem of identification for memory that may be fixed based on thephysical layout of the memory region and/or the hardware utilized toaccess the memory location. For example, a physical address (e.g., mayalso be referred to as a real address, binary address, etc.) may be amemory address that is represented in the form of a binary number on theaddress bus circuitry for physical hardware. The physical memory addressmay be used in order to enable the data bus to access a particularstorage cell of main memory (e.g., RAM). Physical memory may refer tothe actual memory locations used to store data within the hardware ofthe device, rather than virtualized locations generated and maintainedby the operating system in order to simplify or abstract memoryaddressing for processes or tasks that are being executed. For example,physical memory may be assigned a non-modifiable (e.g., not modifiablein software) physical memory address that is not subject to change basedon modifications of address translations by a VMM. Virtual memory blockson the other hand, may be subject to addressing changes configured bythe VMM. Using physical memory locations may allow for the data to bemore easily protected and/or prevent unauthorized access to the data.Utilizing the protected kernel memory may result in routines that accessthe data to be compiled with the OS. However, some system utilities maybe used to provide services and/or memory access to process withouthaving the processes recompiled with the Secure OS.

In an example, the Secure OS may be configured to disable coprocessorsand operate using only the primary processor. A single primary processormay be used even if the main volatile memory is not shared. In anexample, the Secure OS may be configured to turn off and/or restrictaccess to video memory. In an example, the Secure OS may be configuredto dismount non-volatile memory storage (e.g., flash, memory, etc.). TheSecure OS may be configured to disable one or more input/outputinterfaces (e.g., Bluetooth, NFC, circuit-switched voice radios, etc.).These functions may be performed in order to limit potential avenues formalicious attacks against the Secure OS.

At 206, assuming the validation check was passed, the secure processingmay be performed while the device is in protected mode. For example,secure operation to be performed may be a secure voice call, sendingand/or receiving secure email, and/or some other data operation forwhich additional assurance or security is required. As an example, asecure voice over Internet protocol (SVoIP) phone call may be performedin protected mode. The SVoIP process may be performed using the SecureOS to access an enterprise server in order to connect users by IPaddress. The call itself may be configured using standard protocols suchas RFC 3711 Secure Real-time Transport Protocol, RFC 3261 SIP: SessionInitiation Protocol, and/or the like.

At 208, once secure processing tasks have been completed, the Secure OSmay be returned to a known state prior to returning to unprotected mode.For example, any data not present during initial validation of theSecure OS image may be deleted and/or a pattern may be rewritten tounused volatile memory. The Secure OS image used may be unchanged fromthe image that was initially loaded. The pattern written to unusedmemory may be different than the initial pattern.

At 210, the Secure OS may be terminated. In an example, the Secure OSmay be terminated using a privileged software utility that restarts theCOTS OS. There may be no changes to the Secure OS from operating thesecure session. At 212, the COTS OS may be restored based on the imagethat was written to non-volatile memory. The COTS OS maybe restartedusing a restore operation (e.g., BIOS) and/or by writing into thevolatile memory from storage (e.g., a UBoot or Kexec operation).

Upon egress from protected mode, the Secure OS may be configured torestore the unprotected mode OS and/or terminate itself (e.g., theSecure OS) without saving data and/or making changes to the Secure OSimage. In an example, the Secure OS may be configured to remain in itsinitial state throughout the protected mode session. The Secure OS maybe configured to return the volatile memory to a state similar to itsinitial state prior to exiting protected mode (e.g., although a newpattern may be written to unused memory, for example based on newlyprovided challenge parameters). Returning the volatile memory to a knownstate may prevent data generated during the protected mode session frombeing accidentally and/or purposefully exposed to the native OSassociated with the unprotected mode. By returning the Secure OS to itsinitial state prior to exit of the protected mode, the device may beable to ensure that protected information from a secure session is notexposed in the unprotected mode.

In an example, the integrity of the protected mode (e.g., ensuring thesecure OS is operating according to expectations) may be validated andmonitored by a trusted means, for example a trusted monitor (TM) such asa reference monitor. A TM may be utilized to inspect the unused memoryto ensure that the pattern is correctly stored. Examples of referencemonitors such as external reference monitors (XRMs) and/or enterprisereference monitors (ERMs) are described in U.S. patent application Ser.No. 13/665,144, filed Oct. 31, 2012 and entitled “External ReferenceMonitor,” the contents of which are hereby incorporated by reference inits entirety. The Secure OS may be configured to interact with aTM/reference monitor in order to validate that the Secure OS wasproperly instantiated (e.g., prevent unauthorized data and/or executablefrom the native COTS OS from persisting across the transition toProtected Mode), validate that the Secure OS operates correctly and/oraccording to expectations during the period in which the device operatesin Protected Mode, and/or validate that the Secure OS is properly shutdown (e.g., prevent unauthorized data and/or executable from the nativeCOTS OS from persisting across the transition to Unprotected Mode). Theresults of the validation tests may be stored in an audit log of the TMthat documents tests performed during protected mode operation and/ortransitions to and/or from protected mode.

A copy of the Secure OS image may be provided to a TM for validationpurposes (e.g., inspection during protected mode operation). Forexample, a single TM may monitor the operation of multiple devicesoperating in protected mode, for example via communications exchangedover a communication network and/or local or peer-to-peer communicationchannels. During operation in protected mode, the device may beconfigured to interact with a TM to ensure proper operation. Forexample, the TM may inspect the memory regions of the device thatinclude the image of the Secure OS, memory regions associated withapplications running on the Secure OS, and/or unused memory regions(e.g., unused RAM). By inspecting the volatile memory regions that maybe operated on by the device during protected mode operation, the TM mayensure that malware or other malicious programs do not affect operationwhile the device is in protected mode. In an example, the Secure OS maybe specifically configured to include applications utilized to detectmalware and/or compromised software.

The methods and systems described herein may be utilized to supplementand/or replace a trusted boot process, for example if the instantiationof a secure OS is validated with remote attestation by a TM (e.g., XRM,ERM, IRM, etc.) at the time of secure processing. In this manner, themethods and systems described herein may be applied to a COTS computingdevice without the use of a hardware root of trust internal to the COTSdevice, while still providing stronger security guarantees to the user.

During protected mode operation, some or all used and/or unused memorymay be written to a known pattern for a validation test. For example, achallenge/response validation test may be implemented using internaland/or external trusted monitors (e.g., a TM such as an XRM, IRM, ERM,etc.). In an example, validation may include determining a hash checksumof the binary image of the Secure OS that is operating in volatilememory (e.g., dynamic memory) after the Secure OS is restored to memory.The hash checksum may be compared to an expected result, for example asindependently determined by the TM based on the expected state of theSecure OS. Such verification may detect possible subversion of theSecure OS utilized in protected mode by malware by detectingunauthorized changes to the binary image of the OS.

When used herein, the term image may refer to programs and/or other datathat are stored in volatile memory (e.g., processor memory, programmemory, dynamic memory, RAM, etc.). The term volatile memory may be usedherein to refer to memory accessed by the processor in order to executean operating system and/or one or more programs or executables on thedevice. Volatile memory may refer to and/or may be described as one ormore of processor memory, program memory, dynamic memory, RAM, and/orthe like. The term file may refer to programs and/or other data that isstored in non-volatile memory. An image may be created in volatilememory by copying a file from non-volatile memory to the volatilememory, by compiling file(s) and storing the results in volatile memory,and/or otherwise creating a binary image from a file stored innon-volatile memory.

Once the native OS image has been copied to non-volatile memory (orterminated), an operating image associated with the Secure OS may beinstantiated on the device, for example using a restore operation or aboot operation. The primary difference between the restore and bootoperations may be the source and/or type of non-volatile file used toload the Secure OS. For example, the Secure OS may be instantiated as a“Restore” of an operating image of the Secure OS that is stored in oneor more files of non-volatile memory. For example, a restore file may becreated by copying the OS image from volatile memory to a file stored innon-volatile memory. A restore may be made after the OS has beeninitially created through a boot operation. Use of a restore file mayresult in a more predictable operating image being loaded intonon-volatile memory, for example if a boot processes results in anon-deterministic image being loaded into volatile memory. In a restoreoperation, the version of the Secure OS that is loaded on the device maybe ensured to be an accurate replica of the binary image that isexpected to be loaded, making inspection of the image afterinstantiation easier to perform. Thus, in an example a “restore” of theSecure OS may be performed to copy a binary image of the Secure OSdirectly to RAM upon transition to protected mode.

In another example, one or more files stored in non-volatile memory maybe compiled from source code. Compiling source code to instantiate theOS may be referred to as a “boot” of the OS. The compiler may beconfigured to generate a deterministic result in order to ensure thefinal result of the booting process (e.g., the operational image of theSecure OS) is an accurate copy of the binary image expected by the TM.Such a boot may be different than a traditional boot process, which mayrely on one or more non-deterministic techniques in order to create theoperational image of the Secure OS. For example, in a non-deterministicboot procedure, the boot files may instantiate a kernel image, and thekernel image may retrieve and execute one or more files containingcommands (e.g., the kernel may run one or more scripts or commands thatcan alter the final, operating image of the boot version of the SecureOS in a manner that can be difficult to predict in advance). A bootedversion of the Secure OS may still provide adequate levels determinism,for example if the boot file containing the kernel also contains thebulk of the OS and application code such that very few scripts may beused.

Many COTS OSs may not be deterministic, particularly during a bootprocess. As an example using a typical, non-deterministic boot process,a hashing analysis of the resulting OS can show that up to 75% (andbeyond) of the memory image of the Linux OS may vary between two bootsof the OS on the same device. Part of the non-deterministic nature ofthe boot process can be attributed to factors such as system servicesbeing started asynchronously by a scheduler, system resource locationsbeing randomized by Address Space Layout Randomization (ASLR), the useof virtual memory (e.g., meaning that the current contents of devicememory may be dependent on application execution history), and/or thelike.

The non-deterministic nature of such processes may make it extremelydifficult to detect unauthorized modifications to the OS by malware.Although some known malware may be detected using known signatures, suchtechniques may be less reliably used against sophisticated adversaries(e.g., nation states) and/or zero-day attacks. While transitioningto/from and/or operating in the protected mode, the Secure OS may beconfigured to prevent non-deterministic behavior, for example to allowthe device to be brought to a known, verifiable state for entry and exitof the protected mode. Although restricting the Secure OS to operate ina deterministic manner may cause the device to provide a more limitedfunctionality while operating in protected mode (e.g., the Secure OS maylack support full, generalized system services), by doing so the stateof the Secure OS may be verifiable at all times during protected modeoperation. Additionally, such limited functionality may be acceptable tothe user, as unprotected mode may be utilized in order to supportprocesses and services that may not be supportable in a deterministicprotected mode.

By changing the identity of the OS when entering into protected mode,the Secure OS may be designed and configured in such a way so as toensure that the binary operating image of the Secure OS may be veryclose to the originally provisioned image to a relatively high level ofdetail. In typical OS memory structures (e.g., during typicalunprotected mode operation), the applications running on the system canchange the OS state through various processes such as schedulingoperations, swapping virtual memory pages, operating on stack data,utilizing wake locks, etc. Even when applications are idle, the systemvariations and/or residual variations within the OS may be large,leading to data structures that can vary greatly from their initialstate and may be different each time the OS is executed even whensimilar tasks are being performed. For example, a process table may listprocesses in different orders based on the history of the system. Suchdifferences may lead to changes of the operation image of the OS uponboot. Without isolating the OS utilized during protected mode operationfrom such effects, it may be difficult or near impossible to validatewith certainty that the protected mode is operating securely. Therefore,the Secure OS may be operated in a deterministic manner to ensureconsistent operation (e.g., perhaps with a more limited functionalitythan is utilized in unprotected mode). As a result of the ProtectedMode's determinism, the external validation is highly effective atdetecting changes.

The approach of provisioning a highly predictable OS that allows OSvalidation for entry and/or exit of the protected mode and monitoring ofoperation within the protected mode with an TM may increase the securityof the system for performing secure functions while still providing asingle device allowing the user to execute typical applications like webbrowsing and gaming. In addition to the Secure OS, one or moreapplications and/or processes may be inspected by the TM and/or theSecure OS itself during protected mode operation. In an example, theapplications allowed to operate during protected mode may bedeterministic in nature such that their state at any given moment intime may be predicted and validated by the Secure OS and/or by a TM. Inan example, even non-deterministic programs may be utilized while inprotected mode, although the non-deterministic software may be loadedand installed after the device has entered protected mode and the SecureOS instantiation has been verified. In this manner, evennon-deterministic programs may be made more secure, as they may besubject to the control of the Secure OS, which would have been verified(e.g., and perhaps continually verified) to ensure expected operationalstates are maintained.

In general, memory may be identified as volatile or non-volatile.Non-volatile memory may often be the source of the OS (e.g., OS filesare stored in non-volatile memory while the device is powered down),while volatile memory may be used for program and/or OS execution.During operation in protected mode, the Secure OS may be configured toprevent access to non-volatile memory regions. However, there may be oneor more regions of volatile memory (e.g., dynamic memory, RAM, etc.)that may be unused (e.g., not occupied by the Secure OS and/or anypreinstalled applications or utilities). During mode transitions (e.g.,during validation that is performed during the transition to and/or thetransition from protected mode), there may be one or more portions ofvolatile memory (e.g., RAM) that is not occupied by the Secure OS. Theseunused memory locations may be used by the Secure OS while in protectedmode in order to execute Secure OS extensions and/or applications thatare not part of the initial Secure OS verification process (e.g.,programs that may be non-deterministic in nature and/or that were notverified with the Secure OS when entering the protected mode). In orderto protect this unused memory from exploitation by malware (e.g.,malware being imported from the unprotected mode, copying of protectedmode data such that it is accessible in unprotected mode), a specifiedpattern may be written to the unused memory locations for thetransitions to and/or from protected mode (e.g., and/or during protectedmode operation). For example, unused memory that is not part of SecureOS validation could potentially be used to exfiltrate sensitive datautilized during operation in the protected mode to malware present whilein unprotected mode. Described herein are systems and methods forgenerating a pattern in these unused memory locations such that if thepattern is not created in the unused memory during validation (e.g.and/or there is an attempt to spoof the validation step by hiding datastructures in the memory), then the changes may be detected by the TM,for example based on the challenge response taking a longer time toprepare than is expected by the TM based on the requested challenge.

FIG. 3 illustrates an example of an external or trusted monitor beingused to validate entry to and exit from protected mode. For example, at302 the device may be operating in unprotected mode. While operating inunprotected mode, the device may determine to transition to protectedmode. In order to perform the transition, at 304 the device may suspendthe COTS OS and may restore a known, initial version of the Secure OSimage into volatile memory. At 306, an external or trusted monitor maybe used to validate that the initial version of the Secure OS wasproperly instantiated. Validation of the Secure OS may include one ormore interactions with an external reference monitor (XRM), anenterprise reference monitor (ERM), and/or some other TM.

The trusted hardware component may be an XRM, which may be atrusted-hardware processing device that is local to the user, and/or anERM, which may be a trusted-hardware processing device in communicationwith the untrusted device over a communication network (e.g., a serverin an enterprise network setting). The TM may be an IRM, which may beinternal to the device being monitored. The XRM and/or ERM may be usedto provide validation that the Secure OS was properly installed to itsexpected initial state. The XRM and/or ERM may be configured to enforcethe security policies associated with protected mode operation.

Once the initial install of the Secure OS has been validated by theexternal or trusted monitor, then at 308 the device may be performingsecuring processing using the secure OS (e.g., perform a secure voicecall). Although not shown in FIG. 3, the external or trusted monitor maycontinue to test or validate the Secure OS and/or other devicecomponents while the device is performing secure processing in theprotected mode.

At 310, the device may determine that it should transition back tounprotected mode and may return the volatile memory to a known state(e.g., its initial state, perhaps with a new pattern). The external ortrusted monitor may perform a similar validation than was performed whenthe device entered protected mode. If the validation is successful, at312 the Secure OS may be terminated and the previous COTS OS may berestored. At 314, the device may return to operation using unprotectedmode.

FIG. 4 is a flow chart illustrating an example method for transitioningfrom unprotected mode to protected mode, validating the protected mode,and returning to unprotected mode. For example, at 402 upon determiningto transition from unprotected mode to protected mode the device mayhibernate or otherwise terminate the COTS OS (e.g., the OS that executeswhile the device is in unprotected mode). The termination of the COTS OSmay be performed using hibernation in order to maintain the unsecuresession for re-instantiation upon egress from protected mode. In thecase of many popular operating systems, hibernation may be utilized topreserve data of the unprotected session and may be invoked via the COTSOS. The operational volatile memory data and other data associated withthe unprotected mode session and/or COTS OS may be written to anon-volatile storage device. Although hibernation may not be directlysupported by the Android OS, hibernation may be achieved using theunderlying Linux OS that forms the basis for Android. Since applicationsintended for the Android OS are written such that they may be killed orterminated at any time, in some examples rather than hibernating theentire unprotected session, one or more applications may be terminatedwithout storing state information or other data. In an example, theentire unprotected session including the COTS OS may be terminated andrestarted upon egress from protected mode. Application(s) running in theCOTS OS that are configured to transition the device to protected mode(e.g., a “Go Secure” app, a “Secure Voice Call” app, other apps thattrigger security related functions or applications, etc.) may beconfigured to operate with system privileges that allow theapplication(s) to invoke or start the Secure OS.

At 404, the Secure OS may be started. In order to ensure that the SecureOS is loaded in a known or predictable state, the Secure OS image may berestored (e.g., the reverse operation to hibernation) using an imagethat was previously validated and/or authenticated. In an example, theSecure OS image may be started in the volatile memory from storage(e.g., a Boot or Kexec operation). For example, a Kexec operation mayperform a system call that shuts down the kernel for the COTS OS andstarts the kernel associated with the Secure OS. The Kexec operation maybe similar to a reboot operation but may be independent of the COTSdevice firmware. Uboot may be an example of a boot loader that isembedded in Linux systems that be used to load the Secure OS. Whileloading the Secure OS using a boot operation may be utilized, additionalsecurity enhancements may be achieved when a memory image for the SecureOS is loaded from non-volatile storage and restored to system memory(e.g., RAM). For example, an OS may use scripts and other commands tostart system services, which may result in undesirable changes to the OSimage loaded into RAM. Thus, to ensure an expected image orconfiguration is loaded into volatile memory, a deterministic proceduremay be used to load the same binary image of the Secure OS into volatilememory. The image of the Secure OS may be created from a snapshot takenof the Secure OS as loaded for its intended configuration and/or may becreated through a deterministic source code compiler. Examples of OSsthat may be used to create the Secure OS may include Windows (e.g.,Windows in Safe-mode), Linux, and/or Green Hills Integrity. The specificOS chosen may be selected based on implementation specific securityrequirements.

The hardware and kernel for the Secure OS may be configured to minimizeattack surfaces. For example, the Secure OS image may be configured suchthat kernel control data and/or kernel hooks may be aggregated orconsolidated into a protected memory space. In an example, the Secure OSmay be configured to control virtual memory by placing security-relatedand/or security-critical functions in protected kernel memory and/orsome other secure physical memory location. The protected kernel memorymay be a form of physical memory and may use physical memory addressingmodes. Using physical memory locations may allow for the data to be moreeasily protected and/or prevent unauthorized access to the data.Utilizing the protected kernel memory may result in routines that accessthe data to be compiled with the OS. However, some system utilities maybe used to provide services and/or memory access to process withouthaving the processes recompiled with the Secure OS.

In an example, the Secure OS may be configured to disable coprocessorsand operate using only the primary processor. A single primary processormay be used even if the main volatile memory is not shared. In anexample, the Secure OS may be configured to turn off and/or restrictaccess to video memory. In an example, the Secure OS may be configuredto dismount non-volatile memory storage (e.g., flash, etc.). The SecureOS may be configured to disable one or more input/output interfaces(e.g., Bluetooth, NFC, circuit-switched voice radios, etc.). Thesefunctions may be performed in order to limit potential avenues formalicious attacks against the Secure OS.

At 406, the initial state of the Secure OS and/or protected moderesources may be validated. For example, in order to perform thevalidation, the Secure OS may be loaded to a known state. Sincevalidation of the OS may be difficult to perform due to differences inthe operational memory state caused by run-time differences, the SecureOS may be configured (e.g., by performing one or more modifications tothe source code of the Secure OS may prior to compiling the source code)in such a way so as to facilitate validation. For example, the Secure OSmay be configured such that Address Space Layout Randomization (ASLR) isdisabled. In an example, the Secure OS may be configured to utilizedeterministic task scheduling techniques rather than non-deterministictask scheduling algorithms. For example, the Secure OS may instantiateitself without running any scripts.

After the Secure OS has been installed and the device is operating inprotected mode, one or more of the following techniques may be utilizedto facilitate the validation of the Secure OS. For example, a patternmay be applied to unused volatile memory to ensure the memory is in to apredictable state. For example, a one-time-pad and/or a random numbersupplied by an external and secure process may be applied to the unuseddynamic memory. In an example, a hash or some other digest may be usedto capture a digest of the volatile memory image of the device such thatall dynamic memory is captured in a single validation function. A TM orother trusted external hardware may then be used to validate the SecureOS based on the captured image of the dynamic memory range. If the TMdetermines that the device as configured with the Secure OS is secure(e.g., the memory inspection results in the expected value(s)), thedevice may be authorized by the TM to access secure resources (e.g., theenterprise resources; resources for a secure voice call, etc.). If thevalidation check fails, the TM may reject and/or block requests toaccess secure resources, and the user may be informed of the failure.The TM may generate an audit log of the mode transition and/or OSvalidation events.

At 408, assuming the validation check was passed, the secure processingmay be performed while the device is in protected mode. For example,secure operation to be performed may be a secure voice call, sendingand/or receiving secure email, and/or some other data operation forwhich additional assurance or security is required. As an example, asecure voice over Internet protocol (SVoIP) phone call may be performedin protected mode. The SVoIP process may be performed using the SecureOS to access an enterprise server in order to connect users by IPaddress. The enterprise server may rely on the TM providing propervalidation before authorizing the phone call. The call itself may beconfigured using standard protocols such as RFC 3711 Secure Real-timeTransport Protocol, RFC 3261 SIP: Session Initiation Protocol, and/orthe like.

At 410, once secure processing tasks have been completed, the Secure OSmay be returned to a known state for validation prior to returning tounprotected mode. Such a validation may be similar to the validationthat is performed upon entering protected mode. For example, any datanot present during initial validation of the Secure OS image may bedeleted and/or a pattern may be rewritten to unused volatile memory. TheSecure OS image used for validation may be the same image that wasinitially loaded. The pattern written to unused memory may be differentthan the initial pattern. The TM may be used to perform the validationof the challenge response and may log whether the validation wassuccessful or not.

At 412, the Secure OS may be terminated. In an example, the Secure OSmay be terminated using a privileged software utility that restarts theCOTS OS. There may be no changes to the Secure OS from operating thesecure session. At 414, the COTS OS may be restored based on the imagethat was written to non-volatile memory. The COTS OS maybe restartedusing a restore operation (e.g., a restore provided by BIOS) and/or bywriting into the volatile memory from storage (e.g., a UBoot or Kexecoperation).

Several techniques may be used by a TM in order to validate the SecureOS and/or the configuration of the device while operating in protectedmode. For example, in order to perform the validation, the device beingtested may be configured or otherwise brought to known state. Forexample, configuring the device in the known state may include settinghardware configuration registers too known values, specifying thecondition of hardware resources, removing drivers for one or moreinterfaces and/or functions, setting the operating image residing involatile memory (e.g., the Secure OS image, application memory, unusedvolatile memory, etc.) to a known state or set of value, and/or thelike.

When configuring the volatile memory (e.g., RAM) to a known state,different techniques may be applied for inspecting different portions ofthe volatile memory. For example, when operating in protected mode, thevolatile memory may include images corresponding to one or more ofmemory regions utilized by the Secure OS, memory regions utilized byapplications resident in memory during protected mode (e.g.,applications installed in the Secure OS), memory regions correspondingto data structures utilized by the Secure OS and/or in protected mode,unused memory regions, and/or the like. For example, there may be Nbytes of unused volatile memory upon instantiation of the Secure OS andits corresponding resident applications and data. In order to performvalidation, these unused volatile memory regions may be patternedaccording to a known techniques such that an integrity calculation maybe utilized to ensure that malicious code is not hidden within theunused memory.

In order to perform the validation, the different memory regions may bebrought to a known state that is configured such that achallenge/response test issued by the TM is difficult to spoof. Forexample, challenge/response tests may be designed such that it isextremely improbable that the challenge can be passed without the actualvolatile memory being configured as expected by the TM. For example,writing a pattern such as “0xAS” to unused memory may bring the unusedmemory region to a known state (e.g., repeated pattern of 10100101), butsuch a scheme may be relatively easy to spoof without having to actuallywrite the pattern to all of unused memory. Therefore, the pattern may beselected such that it is difficult to spoof the TM challenge.

Portions of the volatile memory that do not include part of thepredetermined memory image (e.g., Secure OS image, application images,data, etc.) may be a relatively large portion of the volatile memory.For example, there may be enough unused volatile memory to store anentire, separate OS. In such a scenario, am unauthorized OS may attemptto execute in the unused memory regions and keep a copy of the secure OSin other memory regions in order to spoof a TM challenge that applied tothe memory regions associated with the secure OS image (e.g., theunauthorized OS may keep as “window dressing” copy of the Secure OS inorder to spoof TM challenges that require an image of the Secure OS tobe stored in memory without actually executing the Secure OS). However,since the unused memory may be used by the Secure OS and/or applicationsoperating during protected mode at some point during the protected modesession, attempts to restrict access to the memory may restrict theresources available to the Secure OS. Therefore, techniques arespecified to occupy these unused memory portions during an initialand/or final memory validation but that allow the unused memory regionsto be used by the Secure OS during protected mode operation.

One method for attempting to secure an unused memory region may be towrite a non-repeating pattern to all of unused memory and include thispattern as “used” memory that is part of the Secure OS image (e.g., thepattern would be part of the OS provisioned to the device or given tothe device as part of the challenge). For example, all of unused memorymay be written with a random bit stream known to the TM. This approachmay be used to occupy unused memory regions in volatile memory, but mayprovide less security because such a pattern may be easily spoofed bymalware. Such a challenge may not provide an adequate test of theproperties of the device. For example, using the simplified patternapproach may not assess a property of the device such that theassessment may be represented in the challenge response.

FIG. 5 is a flow chart illustrating an example method for securingunused memory regions in order to perform validation. The technique forvalidating the unused memory may be performed alone and/or in additionto validations of the Secure OS, the protected mode applications,protected mode data, etc. Although FIG. 5 may be described with respectto a TM validating the memory region to be performed, the validationprocedure described herein may be used in other environments. Forexample, the validation described herein may be used as a confidencetest and/or conformance test to ensure a memory region is configuredproperly. As an example, a device may configured according to a desiredmemory image and a validation test (e.g., digest of the memory regionafter configuration) may be performed to determine a validation result.The user or programmer may know the expected result of the validation(e.g., it may be provided with the software being validated), and if thevalidation result matches the expected response, the user may determinethat the configuration has been correctly installed/instantiated on thedevice. Although validation may be described with respect to validationby a TM, validation results may also be provided directly to a user. Forexample, the COTS device may display a validation result to the user,and the user may compare to result presented to an expected response.

Further, although the validation procedure is described with respect toensuring a device correctly transitioned into and/or out of protectedmode, the validation technique may be utilized to ensure a device thatoperates according to a single mode or configuration. For example, adevice to be validated may operate a single operating system using oneor more applications, and the validation procedure (e.g., includingwriting a pattern to unused memory regions) may be used periodicallyand/or intermittently for a TM to determine that the device is stilloperating according to its expected configuration.

The validation procedure may be designed to bring some or all volatilememory regions into a known or expected state. The memory regions maythen be used as a seed to a hash or some other polynomial function toderive a validation response. If the validation response provided by thedevice matches expected result as independently determined by a TM(e.g., and the response is received within an expected response time),the device may be considered successfully validated.

For example, a hash digest of the contents of some (e.g., certainspecified regions) or all volatile memory regions to ensure that theSecure OS, the protected mode applications, protected mode data, and/ora pattern written to unused memory region(s) are configured in theirexpected state. For example, once the Secure OS is ready to perform avalidation of the protected mode configuration of the device (e.g., at406 and/or 410 in FIG. 4), at 502 the device may contact a TM in orderto request challenge parameters to prepare the unused memory forvalidation. As noted above, the validation may be performed without theuse of a TM, for example where the validation is being performed as partof a conformance test.

At 504, the TM may respond with a challenge. The challenge may includeone or more challenge parameters. For example, the challenge parametersmay include a random number (RND). The random number may be generated bythe TM and may be used to initialize the pattern generator used to writethe random pattern to the unused memory region. In an example, therandom number may be 128 bits long, although other lengths may be used.The challenge parameters may also include a number of pattern generatorcycles over which the pattern is written (K) (e.g., number of times thepattern may be applied to memory locations within the unused memoryregion). The variable representing number of pattern generator cyclesover which the pattern is written (e.g., K) may be limit used by thedevice for a counter (J) as described herein. A larger value of K mayresult in a longer time for processing the validation request as moreoperations may be performed in order to determine the challengeresponse. The challenge parameters may also include an indication of thememory region to be tested. For example, a list of one or more memoryaddress ranges (Z) may be sent to the device as part of the challenge.By varying the challenge parameters (e.g., the number of generatorcycles (K), the indication of the memory regions to test (Z), etc.), thechallenge and/or validation test may be tailored in order to take aspecified amount of time to complete (e.g., based on the hardwarecapabilities of the device being tested). Therefore, the amount of timeto complete the challenge may be a secondary check used by the TM (e.g.,in addition to the actual challenge response/digest value) to ensurethat the validation is successful. In an example, a longer test may beused for the validations dues the transition to and/or from protectedmode (e.g., to ensure the probability that the pattern binds each memorylocation is sufficiently high), while a shorter challenge may be used totest the device periodically and/or intermittently during protected modeoperation (e.g., to ensure processes operating during protected mode arenot starved of processing resources during an extended validationprocedure). The pattern may be written to the unused memory prior todetermining the challenge response. He value K may be chosen so that thepattern will be written a sufficient number of times that theprobability of a memory address in the range Z will not be used for thepattern is low, provided that a random and/or pseudorandom memorylocation is selected for each pattern generator cycle.

In order to write the pattern to the unused memory region(s) based onthe received challenge parameters, at 506 the device may initialize theunused volatile memory to an initial state based on the received randomnumber (RND). The initial values may be set such that each individualmemory region includes a random number with a roughly equal number ofbinary ones and zeros. It may be more difficult to spoof the challengeif the distribution of binary ones and zeros is close to equal.Additionally, in an example, each value may be different than each ofthe other values within the memory region.

For purposes of explanation, an example mathematical frameworkdescribing the operations used to write the pattern on unused memory isdisclosed. For example, in the simplified memory region illustrated inFIG. 5, the volatile memory may include M memory locations, of which Nmemory locations may be unused. For purposes of description, the unusedmemory locations may be designated as locations 0 to N−1, while theSecure OS, one or more programs/utilities, and/or data may be stored atlocations N to M−1. Such an arrangement is used to describe the patterngeneration process, although in many scenarios the unused memory regionsmay be relatively mixed with used memory regions. Specific memorylocations and/or address may be designated and/or referred to with thevariable L, and the binary value stored at that memory address may bedesignated and/or referred to using the variable V. The set of memoryvalues corresponding to memory location L may be represented as V[L],where V may be a vector of binary words indexed by L.

The unused memory may first be initialized prior to being patternedusing several mathematical functions. For example, the initialization ofthe memory values V[L] for L={0 to N−1} may be performed in a variety ofways. One or more methods may be used in order to initialize each of thevalues in the unused memory region to a configuration that includes arelatively even distribution of binary ones and zeros. Theinitialization of unused memory may be configured to set the memory to aknown state (e.g., a state known to the TM) that is non-trivial (e.g., atrivial initialization may be an all-zeros state that may result from“reset”) and non-repeating. For example, the following initializationdefinition may be used:

For L=0,V[0]=RND  Equation (1)

For L={1 to N−1}V[L]=L+RND  Equation (2)

The technique utilized to initialize the unused memory region may alsobe known the TM.

Once the unused memory has been initialized to known values, then at 508a counter J may be initialized (e.g., initialized to 1). A function thatis based on the value of the counter J may be used to determine a memoryaddress to use as part of the challenge. For example, there are manypossible functions “f(J)” that may be used to determine the sequence ofmemory addresses to utilize for writing the pattern. For example, thefunction may be a unity function (e.g., use J directly). In this case,each of the unused memory regions may be processed in an incrementalfashion (e.g., where L=f(J)=J). Another function f(J) that may beutilized may be a linear feedback state machine (e.g., a pseudorandombinary sequence (PRBS) generator). The linear feedback state machine mayuse its previous state value (e.g., the previous memory address f(J−1))in order to determine the next value using a linear function such as anXOR. Other example functions f(J) may include encryption algorithmand/or encryption modes (e.g., counter mode (CM), cipher block chaining(CBC), etc.), and/or a hash function (e.g., cryptographic hash functionssuch as MD4, MD5, SHA-1, SHA-2, etc.).

Additionally, for each memory address L, a function may be used to writea new value to the address in order to complete the challenge. In orderto prevent spoofing of the challenge, the order of operations on L thatchange V[L] may be randomized using a function that cannot be expressedin a closed form as a function of J, the independent variable. If thevalue V may be expressed as a closed form function of J (e.g., V(J)),then it may be relatively easy to spoof the challenge as the malware maybe able to calculate appropriate values of the memory location withouthaving stored the previous values of V at other memory locations.

Although many different types of non-closed form functions may beutilized to select memory address f(J) and/or write value V, a hashfunction will be described as an example. By using a hash function, theorder of memory operations may become highly randomized. In thisexample, J may be assumed to be a linear counter that starts at 1. Notethat f(1) may address any actual memory location as the startinglocation (e.g., f(1) need not correspond to the first memory location inthe unused memory space).

The following processing sequence may be performed K times as shown inFIG. 5. For example, each memory location that is modified may beconsidered a pattern generator cycle, and/or each time the counter J isincremented may be considered a pattern generator cycle. At 510, J maybe translated/transformed to a physical memory address, for exampleusing a hash function. In an example, the number of significant binarydigits of the counter J may be relatively small, for example 32 bits. Inorder to add entropy to the hash function, the value J may be extendedby concatenating J with the random number (RND), for example where J mayrepresent the least significant bits of the result. If the hash functionis represented by the function f, then the hash result, f(J), maycorrespond to the memory region for which the new value will be written.The hash result f(J) may be segmented into a series of memory addressvalues. For example, an example hash function SHA-1 may output a 160 bitresult, while memory addresses may be comprised of few than 160 bits(e.g., 32 bits). Thus, for an example using SHA-1, each hash outputstring may be segmented into five physical memory addresses. Forpurposes of explanation and simplicity of description, all of the fiveaddresses (e.g., either singularly or together) may be referred togenerically as f(J).

Each candidate f(J) may be be range filtered. For example, there may bemany values of f(J) that do not correspond to any memory address withinthe unused memory region. If the unused memory region occupies N bytesof physical memory, then at 512 the device may determine whether thevalue of f(J) corresponds to a physical memory address within the Nbytes. If the value does not fall in to the region of unused memory,then at 514 the value f(J) may be dropped and the next value of J may bechecked. Since f(J) may represent a plurality of physical memoryaddresses, the addresses within f(J) may be taken in a specified order(e.g., first to last), one or more of the addresses may be disregarded,and/or some addresses may be disregarded (e.g., those falling outsidethe specified memory range), while others may be used. The same values(as explained below) may be written to each of the addresses within f(J)or each addresses within f(J) may be processed consecutively and mayhave different values written (e.g., based on the value J and thepreviously written value for a memory address).

When the range of L is relatively small as compared to an indexrepresented by f(J), it may be beneficial to generate f(J) in ways thatreduce the number of values that are found to be out of range at 512. Asan example, if the range of L={0 to 100,000}, then most values of f(J)will be out of range. In the above example, f(J) was described as abinary 32 bit numbers, for example for use with common computerarchitectures/memory indexing schemes. Then, the upper limit of therange of f(J) may be approximately ˜4.3×10⁹, while approximately ˜2×10⁻⁵of the values generated for f(J) are in the range of L. In such case,many suitable enhancements to the generation procedure may be utilized,including reducing the length of f(J) to roughly 17 bits or using themodulus math function, MOD. Such methods may be used to increase theefficiency at which memory addresses within the desired ranged aregenerated. For example, assuming an upper range for L=100,000, addingMOD function to the generator f(J) may result in:

f=f(J) MOD 100,000  Equation (3)

Such a modulus scheme may ensure resulting values f′ being within theposited range of L. However, in many practical scenarios, the unusedmemory regions and the occupied memory regions may be comingled withinL, so even if a modulus or some similar operation is utilized, thememory region may still be checked to ensure that the determined valuefor f corresponds to an unused memory location.

When f(J) addresses one of the N memory locations to be patterned, at516 the memory locations corresponding to address f(J) may be writtenaccording to a function g, where g may be a function of J and V, where Vmay represent the value written to the memory location f(J)−1 (e.g., thememory location immediately preceding f(J)). However, the values ofother memory locations other than the memory location immediatelypreceding f(J) may be utilized for the function g (e.g., memory locationafter f(J), a memory location a specified distance from f(J), a memorylocation that is a distance away based on J, etc.).

The function g may be used to modify the selected memory location f(J).The function g that may take the value of the preceding memory location(or some memory location with a specified relationship with respect tolocation f(J)) and the value of the counter J as an input. For example,the value stored in the previous memory location (e.g., V[f(J)−1]) maybe combined with the value of the counter J to determine what value inthe pattern should be stored at location f(J) (e.g., stored as the newV[f(J)]. In an example, the value stored in the previous memory location(e.g., V[f(J)−1]) may be XORed with the value of the counter J, forexample as shown in Equation (4).

V[f(J)]=V[f(J)−1]XOR J  Equation (4)

Other functions that output a value based on the value stored in theprevious memory location (e.g., and/or some other memory location withinthe pattern and/or volatile memory region) and a value of the counter Jmay be used (e.g., hash, polynomial function, binary function, etc.). Inorder to determine the next memory location to be modified in arelatively random (e.g., pseudorandom) manner, J may be incremented(e.g., at 520) and hashed, for example after being concatenated with therandom number. In another example, after incrementing J, the new,incremented value of J may be concatenated with the identity/address ofthe previously modified address in the pattern and input into a hashfunction in order to determine a new memory location for the pattern.Once J and one or more other parameters have been input into the hasfunction (e.g., J alone, J and the random number, J and the previousmemory location, etc.), the result may be used in a manner similar tothat for the previous value of J (see e.g. 510 above) to determine thenext location to bind to the pattern.

In this manner, f(J) may cycle through the memory locations L in apseudorandom order. The pseudorandom function may be selected to be aone-way function based on J, such that the result if the pseudorandomfunction cannot be used to determine what value of J was used todetermine the result (e.g., if the result of the pseudorandom functionis known (hash result) it is nearly impossible to determine what valueof J resulted in the result that is known). In an example, the firstmemory address in the pattern may be selected based on the hash functionresult of the counter J with the random number (e.g., concatenating Jwith the random number). For each, pattern generator cycle, J may beincremented subsequently applied to the hash function (e.g., with orwithout concatenation of the random number), and the result may be usedto selected the next appropriate memory location. When J is concatenatedwith the random number, J may represent the least significant bits forthe seed to the pseudorandom (e.g., hash) function.

Once the pattern is g(V, J) has been written at memory location L=f(J)(e.g., based on the value associated with the address f(J)−1 and thevalue of counter J), then at 518, the device may determine whether J>K.If so, the pattern may be completed at 522, and the unused memory may beready to be verified/validated. If not, at 520, J may be incremented andthe next physical memory address location may be determined (e.g., f(J+1)). The sequence may be repeated until J>K. Once J>K, the device maydetermine that the volatile memory is in a form that is ready forvalidation with the TM. Therefore, at 522 the validation may beperformed based on the memory contents after the pattern has beenwritten to the unused memory. For example, the device may perform adigest or hash function over some or all of the memory range in order tovalidate one or more of the Secure OS, applications utilized inprotected mode, protected mode data, and/or unused volatile memory(e.g., with a pattern written to the unused memory).

FIG. 6 illustrates an example memory region that may be patterned basedon the example process flow described with respect to FIG. 5. As shownin FIG. 6, memory locations 0 to N−1 may represent the unused memoryregion, and memory locations N−1 to M−1 may represent the memory regionutilized by the Secure OS, secure applications, secure utilities,sensitive data, etc. The addresses may be selected as a function of thecounter J in the form f(J). The value stored at each address f(J) (e.g.,represented by V[f(J)] in FIG. 6) may be a function of the value ofcounter J and the value associated with memory location immediatelypreceding it (e.g., in the case of location f(J), the value V[f(J)] maybe determined based on the value J and the value V[f(J)−1] stored atmemory location f(J)−1) although other memory locations other than or inaddition to the preceding memory location may be utilized.

Once the pattern has been written to the unused memory locations, theentire volatile memory region may be inspected or validated using achallenge. For example, a digest of the entire volatile memory region(e.g., including the Secure OS image, application memory, sensitivedata, unused memory including the written pattern, etc.) may bedetermined, for example based on a challenge vector Z. In an example, Zmay specify or indicate that the entire memory region is to me includedin the digest calculation (e.g., Z={0 to M−1}). For example, a hash maybe performed starting with the memory location corresponding to byteM−1, and the hash may be continued by moving down the memory stack to adesired ending location, for example until the entire memory has beenhashed. In an example, the hash may be performed until at least word N(e.g., the memory regions including the Secure OS and other protectedmode data, but not the unused memory regions) as an atomic operation ofa hash utility (a routine that executes to completion). If, for example,the unused memory were hashed first, malware may be able to potentiallyspoof the challenge as follows. First, the malware could perform thepattern function while resident between locations N and M−1. Then, aftercompleting the hash of words 0 to N, Malware could move within are 0 toN and load the expected OS into memory region N to M−1 before completingthe hash, thus spoofing the challenge in an undetected fashion. It isnoted that the secure OS may be hashed after finishing writing thepattern to unused memory. If the hash of the OS is performed prior towriting the pattern, one or more of the pattern writing operations mayalter the state of the OS in such a way so as the result of the hash ofthe OS after writing the pattern is different than the result of thehash prior to writing the pattern.

Writing a pattern to unused volatile memory may strongly enhance thesecurity and isolation of the Secure OS and/or the protected mode. TheSecure OS image may be relatively small compared to the size of theoperating image of the COTS OS. For example, the Secure OS may occupy avery small portion of the volatile memory of the COTS device. As anexample, a Secure OS and/or other resident secure executable/data mayoccupy less than 50 Mbytes of memory, which may be less than 5% of theavailable volatile memory on many typical COTS devices. Thus, the unusedmemory regions may provide a large attack surface for attempts tocompromise the Secure OS and/or protected mode operation. By writing thepattern to unused memory, the memory regions included in the patternmade be bound to each other, making it extremely improbable that malwarecan successfully operate in the unused memory region. Instead, a malwareattack may attempt to utilize memory in the region occupied by theSecure OS (e.g., region L={M−1 to N}) in order to propagate an attack.However, since the Secure OS may be of minimal functionality,overwriting any portion of the Secure OS may result in a high likelihoodof functional failure of the device and/or detection by the user and/orTM. Further, in order to further decrease the likelihood of a compromisedue to overwriting data within the Secure OS image, the size and/orfunctionality of the Secure OS may be reduce in order to increase thelikelihood of changes to the operating image of the Secure OS leading toOS failure and/or being detected by the user.

The hash result of the memory scan may be sent to the TM for validation.In an example, the TM may perform a check of one or more of the resultof the hash function as determined by the device and the amount of timeit took the device to respond with the challenge answer in order tovalidate that the device is operating the in accordance with theexpected configuration.

For example, the TM may measure the amount of time it take for the COTSdevice to send the challenge response after it has received thechallenge parameters. Based on the TM's knowledge of the capabilitiesand configuration of the COTS device (e.g., memory size, processorspeed, complexity of calculations, etc.), the TM may select a value forK such the COTS device processing to complete the challenge will take asignificantly longer amount of time relative to the network messagejitter. For example, the value of K may be selected in the range of32,000,000 (e.g., generating >160,000,000 random addresses). Such avalue may result in an expected response time in the range of 1 secondusing a typical COTS smartphone as an example, while network messagejitter may be in the range of less than 0.02 seconds. In this manner,the TM may assume that the response time is almost entirely due to thecalculation of the challenge response. The expected response time may beaccurately determined based on the COTS device parameters and thechallenge parameters. If the device does not respond within an expectedresponse window, the TM may consider the challenge to have failed.

The TM may be configured to perform the challenge in a similar manner asthe COTS OS. For example, the TM may block off a portion of TM memory,and use this memory portion to store an image of the Secure OS (e.g.,the image to be restored and validated on the device), to store one ormore applications, utilities, and/or data that are stored on the devicevolatile memory while in protected mode, and/or to write a similarmemory pattern as is written in the unused memory region of the device.In essence, the TM may create a local copy of the expected binary memoryimage that is to be validated in the COTS device using the challengeparameters that were provided to the COTS device. The TM may determine ahash value for its copy of the COTS memory that it has created, and maycompare the result to what it receives from the device. The TM maydetermine a response time (e.g., a response time window) when asuccessful challenge response is expected to be received, for examplebased on the mode of operation of the device, the processingcapabilities (e.g., speed, capacity, etc.) of the device, the challengeparameters, and/or other information related to the capabilities of thedevice, If the results match, the TM may consider the validationsuccessful (e.g., the TM may determine that each bit of volatile memoryis configured to the expected state), while if the results differ, theTM may consider the validation to have failed. In an example, in orderto conserve processing resources at the TM, rather than determining thechallenge answer in near real-time using generated challenge parameters,one or more challenge answers may be precomputed based on theircorresponding challenge parameters and stored at the TM. In this manner,the TM may not re-compute the challenge response for each issuedchallenge; instead relying on the precomputed challenge/responses thatare securely stored on the TM.

Rather than, or in addition to, performing validation when the device isentering or exiting protected mode, one or more validation proceduresmay be performed in near real-time to monitor the Secure OS, otherapplications, and/or unused memory regions. Additionally, the TM may beconfigured to adjust the values supplied for K and/or Z in order toprovide for quicker responses and/or increased levels of assuredness.For example, the proposed validation approach may be used to monitor aseparation kernel for implementation of a virtual machine. The memoryregion Z may be specified to correspond to the separation kernel thatimplements the virtual machine.

In an example, during protected mode operation, periodic and/orintermittent validation may be performed to the Secure OS to ensure theSecure OS is operating according to expected procedures. For example, inorder to inspect the Secure OS, Z may be set to correspond to the memoryregion L={M−1 to N} and/or K may be set to a relatively small number,for example a number sufficient to cover most or all OS memorylocations. For example, certain small, relatively unexploitable memoryregions in the Secure OS image may be left out of the memory validationtest. In this manner, the Secure OS may be validated while avoidinginterrupting other operational capabilities. For example, such avalidation of the Secure OS image may utilize few processor cycles,allowing sufficient processing capability for applications whileperforming the validation.

One or more applications that operate while the device is in protectedmode may not be part of the protected mode entry/exit validationprocedure. Such applications may be installed after the Secure OS hasbeen instantiated and validated. In order to provide validation forthese applications (e.g., memory inspection may be difficult, as theoperating state may vary or be unknown), other techniques in addition tomemory inspection may be used. For example, malware scans may beperformed, signatures checks may be utilized, etc. In an example,applications that are not part of the memory inspection validation maybe “white listed” and signed by a trusted source. The Secure OS may beconfigured to verify the signature based on the trust associated withthe Secure OS before the application can be executed in protected mode.

The pattern that is written to the unused memory regions may be selectedto have the property such that the contents of a given memory locationmay depend on the contents of some other physical memory location. Sucha scheme may make it difficult to efficiently spoof the pattern withoutactually writing the pattern to a physical memory location. For example,by “binding” a given unused memory location to another unused memorylocation, each memory location (e.g., other than a seed location) forwhich the pattern is written may rely on a previous memory location tobe used to store a prior result within the pattern and to be availablefor later calculation steps. If malware were to try to spoof the patternwithout actually storing the pattern in physical memory as set forth inthe challenge, significant overhead processing may result in addition tothe processing time that would be associated with an uncompromisedsystem. For example, the number of pattern generator cycles may beselected such that most or all memory locations are bound to thepattern, preventing the unused memory for being used for storage ofmalware. Thus, if the TM determines that the correct result is notreturned within the predetermined threshold amount of time (e.g., thethreshold may be based on the parameters of the COTS device such aprocessor speed, memory size, etc. and/or the challenge parameters), theTM may determine the validation to be unsuccessful.

In an example, the pattern to be utilized may be essentially unique foreach challenge (e.g., based on the pseudorandom nature of how memorylocations are selected), making the challenge response extremelydifficult (e.g., if not essentially impossible) to be pre-calculated bya malware entity. Additionally, the number of processing steps requiredto generate the pattern and/or the number of processing steps requiredto determine the challenge response may be time adjustable, for exampleby varying the challenge parameters (e.g., RND, K, Z, etc.). In order toperform a two-pronged validation, challenge may be configured and/orissued by the TM such that the amount of processing time needed to writethe pattern and perform the digest evaluation of the memory region maybe relatively large as compared to any communication link delays (e.g.,network jitter). In this manner, if the response is either incorrect orprovided after a predefined response window has elapsed (e.g., thewindow may selected based on the device capabilities and challengeparameters), the TM may consider the validation to have failed. Thedevice may be configured to perform the challenge using the highestpriority in order to utilize the maximum number of processing resourcesin order to perform the challenge as quickly as possible. Thus, if theresponse is not received by the TM after the expected time it shouldtake the device to perform the challenge, the TM may consider thevalidation failed. By configuring the challenge to take orders ofmagnitude longer than likely communication network delays, the TM mayassume that the delay is due to the device processing the challenge. Theresponse may be expected to be received within a response time window.For example, the window may begin at a time that is a predetermined timeafter the challenge was sent, where the predetermined time maycorrespond to a determined amount of time it should take the device tocalculate a response. The window may end a given amount of time later,where the given amount of time may be set to correspond to a maximumacceptable amount of time for transmission delays (e.g., sending thechallenge to the device, receiving a response, etc.).

In an example, the initial validation upon ingress to protected mode andthe final validation upon egress from protected mode may be configuredto be extremely robust challenges across the memory regionscorresponding to the Secure OS, protected mode applications, utilities,data, etc., and/or unused memory regions written to a challenge pattern.Subsequent periodic and/or intermittent challenges while the device isoperating in protected mode may be performed for certain memory regions(e.g., the Secure OS region) and/or may utilize a relative shorterpattern calculation time (and/or no pattern) for unused memory regions.The checks performed during protected mode operation may be designed tobe performed in a more power-efficient manner than the initial checks(e.g., to save device resources) and/or may be designed to be shorter inorder to use less processor time so that protected mode applications arenot adversely affected/starved from processing resources.

The pattern may be designed such that the next memory location to selectfor writing the pattern may be chosen in a pseudorandom manner (e.g.,based on an algorithm operation on the current value of a counter Jand/or the current memory location). By writing the pattern into memoryat pseudorandom location and utilizing a pattern where the value writteninto memory is dependent on the memory at some other location and thefunction of J (e.g., the sequence of operations is bound to the finalpattern), the pattern may not be expressible in a closed form. Thismakes the validation determination (e.g., hash or digest), difficult tospoof without writing the actual pattern to physical memory locations.Moreover, the pseudorandom nature of the pattern may cause the sequenceof operations to change for each challenge, preventing exploitation ofthe pattern generator.

The pattern may be generated with a “one-way” function to reduce oressentially eliminate the possibility of hiding a small group of memorylocations (e.g., which may be installed with malware) and usingbrute-force calculation to attempt to spoof the TM for those few memoryelements. For example, even attempting to hide four memory locations maybe shown to result in a detectable performance variance in challengeresponse time in the majority of COTS devices.

For example, consider an attack where the malware occupies four words ofmemory, and attempts to spoof the challenge without writing the patternto those four words of memory. In order to hide a memory locations, whenthe memory address pointer for the pattern (e.g., f(J)) identifies oneof the four locations, rather than modifying the target memory locationwith the appropriate pattern value (e.g., such an operation wouldoverwrite the malware), the malware may “filter out” the address valuesto be hidden and save its own data in those locations. It may thencontinue writing the pattern to other memory locations. Then, when thepattern is complete and it is time to perform the final hash/validationof the entire volatile memory regions, the malware would then need tocalculate the pattern values that should be stored in the four locations(e.g., in sequence of descending addresses). If the malware does notdetermine these values, then the hash check may fail.

Given the function utilized to select the patterned memory addresses(e.g., f(J)) is not reversible, the a malware would attempt to find thevalue(s) of J that corresponds to the four hidden addresses by steppingfrom J=1 to P, where f(P) corresponds to at least one of the malwareinfested addresses. Then, the pattern value that should be stored inmemory would be calculated based on P and the value stored at theprevious memory address (e.g., as V[f(P)−1] and P) and fed into thememory hash calculation. In order to perform such a determination, onaverage the malware would operate N/2 calculations of f(J) for eachhidden memory word. Therefore, the malware may utilize 2Ncalculations/processing steps in order to hide four words. Since N mayrepresent the number of memory locations to be validated, it could takethe malware approximately twice as many calculations to hide the fourmemory location as it would take the device to calculate the hash of theentire memory space N. Thus, such a time difference may be utilized bythe TM to detect a spoof. Since the determination of the f(J) may beprocessor-intensive, for many scenarios doubling N essentially triplesthe challenge response time. While four hidden words is used as anexample, even a single hidden word can be detected in many applicationsbecause the intended challenge response time can be scaled to exceedsystem timing variations. Additionally, increasing the amount of time ittakes to successfully perform the challenge may establish a strongisolation between the unprotected mode and the protected mode (e.g.,data cannot leak between modes due to malware and/or software defects).

Moreover, such a determination that is utilized to estimate the timeneeded to spoof the pattern may serve as a lower limit on the amount oftime needed to spoof the pattern, but other factors may also increasethe response time. For example, the above estimate of spoof time assumedthat the value stored at the preceding memory location to f(P) (e.g.,V[f(P)−1]) was known at the instant when V[f(P)] is to be determined. Inmost practical scenarios, the history of each location may be quitecomplex and various memory locations may be overwritten several times,for example where K>>N. Moreover, each time a memory location is writtento the pattern, the value to be written may depend on the current valueof J, which changes over time/course of the pattern. Thus, the malwaremay attempt to utilize a lookup table of J as a function of f(X), whichwould contain K entries. Notionally, this lookup table may be biggerthan the size of the memory to be patterned resulting in additionalcomputational difficulties that may make spoofing the challengeextremely difficult. Moreover, even given a look-up table, thedetermination of the appropriate value to store at f(P) (e.g., V[f(P)])may be unable to be expressed in closed form, making spoofing thecalculation computationally intensive.

Thus, in order to ensure that the unused memory is brought to a knownstate in order to complete the challenge (e.g., in order to preventunused memory from being a means to exfiltrate protected data and/or tohide malware), a pattern may be selected such that the memory locationsfor the pattern may be selected in a pseudorandom fashion and the valueswritten to the memory locations may depend on the value of anothermemory location in the pattern and the order in the pattern for thisoperation (e.g., the value of the counter J). Such a pattern may make itextremely difficult or practically impossible to identify an appropriatevalue to write in a memory location within a specified response windowwithout writing the pattern in the specified order. The pattern is“bound” to the memory such that each value written during patterngeneration may depend on the value written to another memory locationand the order of the given operation within the pattern.

As was noted earlier, to increase performance (e.g., reduce patternwriting time) multiple memory address values may be derived from eachvalue of f(J). Such a technique may utilize the same value of J for eachof the memory locations derived from f(J) and/or may utilize asub-counter in addition to J that may be utilized to providedifferential count values within each memory location f(J) (e.g., thecounter J and the sub-counter may be utilized as an input fordetermining the appropriate value to write to the memory location and/orto select the next memory location).

Although the term COTS device is utilized herein to describe a computingdevice to be validated, any computing device for which additional levelsof assurance or additional levels of security are desired may utilizethe techniques described herein. COTS devices may also be referred to asuntrusted devices.

As noted above, the TM may be a trusted hardware component that isutilized to validate the COTS device. Examples of TMs may includeinternal reference monitors (IRMs), XRMs and/or ERMs. For example, anIRM may be hosted by the device to be monitored. The IRM may be ahardware component internal to the device being monitored. In thismanner, the device may execute a given operating system and the IRM maybe configured to ensure that the device utilizes an expected image ofthe operating system and/or has correctly written a pattern to thevolatile memory that is not used for storing the operating system.

For example, an IRM may be an example of a TM that is used to validatethat the memory of the device that includes the IRM. For example, adevice may be configured to execute an operating system. The device mayinclude memory configured to store an operational image of the operatingsystem. The memory may also store a pattern that is written to at leasta portion of the memory that is not occupied by the operational image ofthe operating system. The device may include an internal referencemonitor (IRM). The IRM may be configured to validate that the memory isconfigured with the correct operational image of the operating systemand the pattern. For example, at least one memory address used for thepattern may be selected based on a result of a pseudorandom function. Avalue of a counter initialized at the beginning of the pattern may be aninput to the pseudorandom function. A value written to the at least onememory address may be determined based on a value that was stored atanother memory address in the memory and the value of the counter usedas the input to the pseudorandom function (e.g., the order in which thememory address is written in the pattern may affect the value written tothe memory address). As an example, the pseudorandom function maycomprise a hash function.

FIG. 7 is an example system diagram of a COTS device (e.g., an untrusteddevice) device and a TM (e.g., an XRM). In the example illustrated inFIG. 7, both COTS Device 700 and TM 710 may be local to the user. Forexample, COTS Device 700 may be a smartphone and TM 710 may be a tokenthat is local to (e.g., in the same location as) the user. COTS Device700 may be any device for which additional security is desired, forexample a smartphone device. For a variety of reasons, a user of COTSDevice 700 may be unable to verify that COTS Device 700 meets a desiredset of security requirements. For example, a security status of COTSDevice 700 may be unknown to the user. In another example, COTS Device700 may be associated with a certain level of security, and TM 710 mayprovide an additional layer of security, for example in order to meetthe desired set of security requirements.

COTS Device 700 may include Untrusted Processor 704 and/or UntrustedMemory 706. Untrusted Memory 706 may be a tangible, computer-readablemedium configured to store data and/or computer executable instructions.Untrusted Processor 704 may be configured to execute the computerexecutable instructions stored on Untrusted Memory 706. Untrusted Memory706 may include volatile memory (e.g., volatile memory such as RAM)and/or non-volatile memory (e.g., Flash memory, a hard drive, etc.).Untrusted Processor 704 may be configured to perform one or morefunctions such as a security function. For example, Untrusted Processor704 may perform authentication and/or encryption/decryption. COTS Device700 may include Untrusted Communication Device 702 (e.g., an untrustedtransceiver or other communication means). In an example, one or morehardware modules included in COTS Device 700 may be unsecure and/or thesecurity status of the module may be unknown. For example, one or moreof Untrusted Communication Device 702, Untrusted Processor 704, and/orUntrusted Memory 706 may be considered untrusted because the user ofCOTS Device 700 may be unable to verify that the security levelassociated with the hardware of COTS Device 700 is able to meet thedesired security level for the user for a given task. An example ofunsecure hardware may be hardware that was manufactured outside of adesignated high-assurance environment. For example, a Type 1 product maybe a device or system certified by the NSA for use in cryptographicallysecuring classified U.S. Government information. If a device ismanufactured in a non-NSA certified facility, the device may beconsidered unsecure and/or may not be a Type 1 product. TM 710 may beconfigured to provide security functionality (e.g., similar to a Type 1certified device) for an untrusted platform.

Untrusted Communication Device 702 may be configured to communicate withTrusted Communication Device 712 of TM 710. For example, UntrustedCommunication Device 702 may communicate with Trusted CommunicationDevice 712 via Bluetooth, Near Field Communications (NFC), Wi-Fi,Ethernet, using IP protocols, via a communication network, usingwireless signals, using a direct physical connection, and/or the like.

TM 710 may include Trusted Processor 714 and/or Trusted Memory 716.Trusted Memory 716 may be a tangible, computer-readable mediumconfigured to store data and/or computer executable instructions.Trusted Processor 714 may be configured to execute the computerexecutable instructions stored on Trusted Memory 716. Trusted Processor714 may be configured to provide security assurance for Untrusted Device702. For example, TM 710 may communicate with COTS Device 700 viaTrusted Communication Device 712 in order to monitor functions beingexecuted by Untrusted Processor 704. In an example, TM 710 may provide atype of security challenge to COTS Device 700. TM 710 may determine asecurity status of COTS Device 700 based on a response to the securitychallenge provided by COTS Device 700.

TM 710 may be implemented in a variety of hardware devices. For example,TM 710 may be implemented in an external module that is coupled to COTSDevice 700 (e.g., a micro-Secure Digital (SD) card, a subscriberidentity module (SIM) card, a module such as flash memory coupled toCOTS Device 700 using interface such as universal serial bus (USB),etc.). TM 710 may be a small, lower power device that functionallyindependent of COTS Device 700, but that is in operable communicationwith COTS Device 700.

TM 710 may be utilized to perform one or more security functions onbehalf of COTS Device 700. For example, one or more of the NSA'sInformation Assurance Requirements Directive (IASRD) securityrequirements may be met by TM 710 on behalf of COTS Device 700. Examplesecurity functions that may be performed by TM 710 may include memorymanagement, determining and/or verifying checksums, determining and/orverifying cyclic redundancy checks (CRCs), determining and/or verifyingintegrity check values (ICVs) data labeling, sequence monitoring, etc.Additionally, it may be possible to transfer security functions fromCOTS Device 700 to TM 710, for example to assist with meeting fail-saferequirements (e.g., preventing tampering, prevent unauthorized events,control access to control keys, etc.).

Embodiments may take the form of a tangible computer-usable orcomputer-readable medium providing program code for use by or inconnection with a computer or any instruction execution system. Examplesof a computer-usable or computer-readable medium include tangiblecomputer media such as semiconductor or solid state memory, magnetictape, a removable computer diskette, a random access memory (RAM), aread-only memory (ROM), a rigid magnetic disk and an optical disk.Current examples of optical disks include compact disk-read only memory(CD-ROM), compact disk-read/write (CD-R/W) and DVD. A processor may beconfigured to execute instructions stored in memory to perform thevarious functions described herein.

What is claimed:
 1. A method implemented in a device to be secured foroperating the device in a protected mode of operation, the methodcomprising: operating the device outside of the protected mode, whereinthe device executes a first operating system when operating outside ofthe protected mode; determining to transition the device into theprotected mode; terminating the first operating system based ondetermining to transition the device into the protected mode; loading anoperational image of a second operating system into the device based ondetermining to transition the device into the protected mode, whereinthe operational image of the second operating system is copied tovolatile memory; determining to transition the device out of theprotected mode; and loading an operational image of the second operatingsystem based on determining to transition the device out of theprotected mode.
 2. The method as in claim 1, further comprising:receiving a first challenge from a trusted monitor (TM), wherein thefirst challenge is received based on the device transitioning into theprotected mode; determining a first challenge response based on thefirst challenge; sending the first challenge response to the TM;receiving a second challenge from the TM, wherein the second challengeis received based on the device transitioning out of the protected mode;determining a second challenge response based on the second challenge;and sending the second challenge response to the TM.
 3. The method as inclaim 2, wherein the first challenge is indicative of a memory region ofthe device that is to be validated by the TM.
 4. The method as in claim3, wherein the memory region is associated with at least a portion ofthe operational image of the second operating system.
 5. The method asin claim 2, further comprising writing a pattern to an unused memoryregion in order to answer the first challenge.
 6. The method as in claim5, wherein a value to be written in the pattern for a given memoryaddress is dependent on the order in which the memory address wastreated in the pattern.
 7. The method as in claim 6, wherein the valueto be written in the pattern for the given memory address is furtherdependent on a value stored at another memory address.
 8. The method asin claim 1, further comprising: storing operational data of the firstoperating system in non-volatile memory based on determining totransition the device into the protected mode; and restoring the firstoperating system using the operational data stored in non-volatilememory upon transitioning the device out of the protected mode.
 9. Amethod for bringing volatile memory to a known state for validation, themethod comprising: receiving a plurality of challenge parameters,wherein the plurality of challenge parameters comprise an indication ofa memory region and a random number; writing a pattern to at least oneportion of unused volatile memory, wherein at least one memory addressto use for the pattern is selected based on a result of a pseudorandomfunction, a value of a counter initialized at the beginning of thepattern is an input to the pseudorandom function, and a value written tothe at least one memory address is determined based on a value that wasstored at another memory address in the volatile memory and the value ofthe counter used as the input to the pseudorandom function.
 10. Themethod as in claim 9, wherein the challenge parameters further comprisea number of pattern generator cycles over which to apply the pattern toselected memory addresses.
 11. The method as in claim 9, furthercomprising: performing an integrity checksum across the volatile memoryonce the volatile memory has been brought to the known state; andtransmitting the result of the integrity checksum to a trusted monitor(TM).
 12. The method as in claim 11, wherein the integrity checksumfunction is performed first over memory values corresponding to theoperational image of an operating system and then across the at leastone portion of unused volatile memory.
 13. The method as in claim 9,wherein the another memory address comprises an adjacent memory addressto the at least one memory address.
 14. The method as in claim 9,wherein the result of the pseudorandom function is utilized to selectthe at least one memory address by translating the result of thepseudorandom function to the at least one memory using a modulusoperation.
 15. The method as in claim 9, wherein a first memory addressin the pattern is dependent on the random number.
 16. The method as inclaim 15, wherein the first memory address in the pattern is selectedbased on a result of a hash function being applied to the counter andthe random number.
 17. The method as in claim 9, further comprisinginitializing the at least one portion of unused volatile memory prior towriting the pattern to the unused volatile memory, wherein the at leastone portion of unused volatile memory is initialized based on the randomnumber.
 18. The method as in claim 17, wherein initialing the at leastone portion of unused volatile memory based on the random numbercomprises: storing the random number at a first determined memoryaddress of the unused volatile memory; incrementing the random number;storing the incremented random number at a next determined memorylocation; and repeating the incrementing of the random number andstoring each iteration at a subsequent memory address until the at leastone portion of unused volatile memory has been initialized.
 19. Atrusted monitor (TM) for validating that volatile memory of an untrusteddevice is configured in a known state, the TM comprising: acommunication device configured to send a challenge to the untrusteddevice, the challenge comprising an indication of a memory region, arandom number, and a number of pattern generator cycles over which toapply a generated pattern to selected memory addresses; a processorconfigured to determine an expected challenge response; the processorbeing further configured to determine an expected response time windowbased the challenge and a configuration of the untrusted device; and theprocessor being further configured to determine that validation of theuntrusted device is successful based on the TM receiving a challengeresponse within the response time window that comprises the expectedchallenge response.
 20. The method as in claim 19, wherein the processoris further configured to: determine an expected state of the volatilememory of the untrusted device based on the challenge, wherein theexpected state of the volatile memory of the untrusted device comprisesa first region configured to store an operational image of an operatingsystem and a second region configured to store a pattern; and determinethe expected challenge response based on the expected stated of thevolatile memory of the untrusted device, wherein the expected challengeresponse comprises a result of a hash function being applied across datacorresponding to the expected state of the volatile memory.
 21. The TMas in claim 19, wherein the communication device is configured to sendthe challenge based on one or more of the untrusted devicestransitioning into a protected mode of operation or the untrusted devicetransitioning out of the protected mode of operation.
 22. A deviceconfigured to execute an operating system, the device comprising: memoryconfigured to store an operational image of the operating system and apattern that is written to at least a portion of the memory that is notoccupied by the operational image of the operating system; and aninternal reference monitor (IRM) configured to validate that the memoryis configured to store the operational image of the operating system andthe pattern, wherein at least one memory address used for the pattern isselected based on a result of a pseudorandom function, a value of acounter initialized at the beginning of the pattern is an input to thepseudorandom function, and a value written to the at least one memoryaddress is determined based on a value that was stored at another memoryaddress in the memory and the value of the counter used as the input tothe pseudorandom function.
 23. The device as in claim 22, wherein thepseudorandom function comprises a hash function.